Трудности

Запустить Конфигуратор из командной строки нетрудно. Трудно другое: платформа отвечает «успех» на неполную работу, помнит только себя и умеет разное в разных инструментах. Здесь собрано всё, что мешает, и рядом — чем раннер на это отвечает.

Номера в скобках ведут на страницу Платформа, к утверждению документации. Пометка замер означает, что факт получен на стенде, а документация о нём молчит.

• Успех платформы не означает полноту
• База помнит только себя
• Инструментов несколько, и умеют они разное
• У расширения два имени
• Два формата исходников
• Что раннер не делает намеренно

Успех платформы не означает полноту

Самые коварные трудности — те, где платформа завершает работу кодом 0, а результат неполон. Узнаёте вы об этом позже и в другом месте.

1. Чужой файл версий ConfigDumpInfo.xml проходит без ошибки замер

Файл версий ConfigDumpInfo.xml платформа пишет рядом с выгрузкой и по нему решает, какие объекты выгружать заново. За свой она принимает любой такой файл, который лежит в каталоге выгрузки. Совпавшие версии объектов она считает неизменёнными и пропускает (17, 19). Если файл описывает другую базу, выгрузка выходит неполной, а отчёт — успешным.

Ответ раннера. Файл версий принадлежит паре «база ↔ каталог» и хранится у раннера. Перед работой по изменившемуся раннер сверяет отпечаток файла в каталоге со своим. Чужой файл подменяется своей копией, разошедшийся каталог переводит выгрузку в полную.

2. ConfigDumpInfo.xml не знает, какую базу описывает

В файле только формат, версия формата и версии объектов (16). Лежит он в каталоге исходников, а каталог один на все базы, к которым его подключали. Две базы на один каталог переписывают файл по очереди, и платформа не замечает подмены.

Ответ раннера. Память о базе живёт под localPath отдельно для каждой объявленной базы и при первом обращении запоминает, к какой базе относится. Если под тем же именем оказалась другая база, эта память объявляется чужой и не используется. Файл версий в каталоге исходников расходный: раннер подкладывает туда копию из памяти нужной базы на время команды.

3. Быстрая выгрузка молча становится полной

Переименование конфигурации или объекта, удаление объекта, правка предопределённых данных или диаграммы бизнес-процесса переводят выгрузку в полную без предупреждения (18). Выгрузка на три минуты занимает сорок, и это штатное поведение.

Ответ раннера. Ответ называет запрошенный режим и рядом — случившийся, с причиной. Долгая выгрузка после переименования перестаёт выглядеть сбоем.

4. Без ConfigDumpInfo.xml пакетный режим отказывает замер

Интерактивный Конфигуратор без файла версий делает полную выгрузку (17). Пакетный режим с ключом -update возвращает ошибку, и ключ -force здесь не помогает: он лечит только несовпадение версии формата (19). Проверено на 8.3.27.2074.

Ответ раннера. Наличие файла и версия формата в нём — дешёвые факты, которые видны до запуска платформы. Файла нет — выгрузка полная, она же его и создаст. Версия чужая — тоже полная. Причина подмены режима называется в ответе.

5. Версия формата задаётся версией платформы

Выгрузка из 8.5 не загрузится в 8.3.27: загрузка принимает формат не новее себя (22). Отказ придёт от платформы, после запуска, своими словами.

Ответ раннера. Версия формата читается из файла версий до запуска. Отказ называет обе версии.

База помнит только себя

Платформа знает, что лежит в базе. О каталоге исходников, о ваших правках и о второй базе она не знает ничего.

6. Поколение отвечает только «то же» или «другое» замер

Идентификатор поколения сравнивается только на равенство, у пустой базы он из сорока нулей (13). Две разные пустые базы по нему неотличимы. Замер добавил ещё одно: токен основной конфигурации у Конфигуратора и ibcmd совпадает, а токены расширений различаются.

Ответ раннера. Токен хранится вместе с именем инструмента, который его выдал. Сравниваются только значения от одного инструмента. Сорок нулей хранятся как отсутствие ответа.

7. Платформа не знает о вашей работе в каталоге

Выгрузка пишет то, что решила писать: объекты с изменившейся версией, при полной выгрузке — все (17). Правок в каталоге, которых нет в базе, для неё не существует, и никакого слияния у выгрузки нет.

Ответ раннера. Выгрузка ложится в каталог обычным изменением, а сводит его система контроля версий: у неё есть история и разметка конфликтов. Когда выгрузка уничтожила бы то, чего система версий не вернёт, раннер отказывается и называет файлы поимённо.

8. У базы есть своё непринятое, и загрузка его стирает

Правка в Конфигураторе живёт в основной конфигурации до применения к базе данных (1, 3). Полная загрузка из файлов и загрузка .cf заменяют основную конфигурацию целиком (11, 23). Частичная загрузка при ошибке откатывается к последней сохранённой и теряет несохранённое (24). Интерактивный Конфигуратор об этом спрашивает (11), пакетный режим работает без диалогов (78).

Ответ раннера. Отправка отказывает, если поколение базы ушло вперёд с прошлой синхронизации, и отправляет к pull. Состояние «есть непринятое» показывает status, а отбрасывает reset; чужое он трогает только с --force.

9. Применение требует монопольного доступа

Обновление конфигурации базы данных — отдельный акт, которому мешают чужие сеансы (3, 4). Динамическое обновление оставляет работающих на старой конфигурации до перезапуска (6).

Ответ раннера. Отправка и применение — разные команды. Разрешение завершать чужие сеансы даёт вызывающий явно; в сессии агента платформа задаёт этот вопрос сообщением (96), и раннер отвечает на него по этому разрешению. Окно обслуживания собирают команды sessions: запретить новые сеансы, завершить старые, применить, разрешить (57). Состояние «обновлено динамически» видно в status --deep.

10. Правку во время синхронизации никто не замечает

Монопольный доступ документация требует для применения (3) и снимка (71); для выгрузки в файлы такого требования нет. Значит, пока идёт выгрузка, базу могут править, и о смеси состояний платформа не сообщит.

Ответ раннера. Поколение спрашивается до операции и после. Если оно изменилось, ответ называет это, и выгрузка считается устаревшей.

Инструментов несколько, и умеют они разное

Одну и ту же работу умеют Конфигуратор, его агент, ibcmd, шлюз автономного сервера и EDT CLI. Никто из них не умеет всего.

11. Покрытие операций у инструментов разное

У Конфигуратора в пакетном режиме нет статуса расхождения (29), свойств расширений (46) и управления сеансами (103); ibcmd работает через файловый каталог или напрямую через СУБД, а подключение по Srvr=…;Ref=… не использует. Для базы кластера прямой доступ допустим только после остановки обслуживающего кластера; иначе возможна порча базы (60). Канал задаётся отдельной секцией dbms. SSH-шлюз автономного сервера не создаёт базу, а сравнения и проверок в его наборе нет (61); полный набор у этой цели даёт Конфигуратор по прямому шлюзу (65). Снимок .dt через ibcmd идёт без проверки монопольного доступа, через SSH-шлюз роняет сервер замер.

Ответ раннера. Исполнителя выбирает пара «операция и цель» по матрице умолчаний. На проводе и во флагах исполнителя нет. Квитанция называет, кто выбран и кто пропущен и почему.

12. Версий платформы несколько, и пути у них разные

Несколько версий на одной машине — штатная расстановка (70). Публикации нужны версия и разрядность, совпадающие с платформой базы (69).

Ответ раннера. Утилиты находятся по маске версии. Отказ называет установленные версии и недостающий компонент.

13. Цель может стоять на другой машине

Кластер и автономный сервер живут где угодно: клиент не знает, где лежат данные (52), а с автономным сервером раннер говорит по сети: Конфигуратором через прямой шлюз и сессией SSH через агентский (65, 61). Их файловая система раннеру недоступна.

Ответ раннера. Конфигуратор по сети держит файлы у раннера. Пути в командах, которые исполняет SSH-шлюз, разрешаются на его стороне, и результат забирается объявленным каналом обмена. Рабочий каталог всегда локален.

14. Ответ платформы — код выхода и журнал

Код различает успех, ошибку и ошибки в данных (77), у команд с расширением остаются только 0 и 1 (45). Всё остальное — проза в файле /Out (78).

Ответ раннера. Решение принимается по коду выхода и появлению результата. Проза переносится в квитанцию как улика и ничего не решает.

У расширения два имени

15. Имя набора в проекте и имя расширения в базе — разные имена

Расширение в базе называется так, как записано в его Configuration.xml: там же лежат префикс имён и назначение (36). В базе это имя уникально и служит идентификатором (37). Набор исходников в проекте называется как удобно проекту, и это второе имя. Заводить расширение через ibcmd или агента надо до загрузки, с именем, префиксом и назначением (34, 35).

Ответ раннера. Соответствие набора и расширения раннер читает из Configuration.xml, объявлять его в конфигурации не нужно. Первая отправка заводит расширение сама с этими свойствами, как git push заводит ветку.

16. Удаление расширения уносит данные

Расширение, расширяющее данные, удаляется в два шага, и его таблицы удаляются вместе с ним (42). Журнала ссылок, откуда это можно достать, у платформы нет.

Ответ раннера. Удаление спрашивает подтверждение жёстче, чем удаление ветки в гите.

17. Частичная загрузка не работает с несколькими расширениями

Документация оговаривает это прямо (24).

Ответ раннера. Отправка идёт по ссылкам по одной: сначала конфигурация, потом каждое расширение.

Два формата исходников

18. Проект EDT — не выгрузка платформы

У EDT своя модель проекта, а обмен с платформой идёт через экспорт в XML и импорт из XML (108). Первый запуск 1cedtcli занимает около 25 секунд (107).

Ответ раннера. У формата EDT две ступени состояния: проект и его экспорт. Экспорт — кеш раннера, и он не под контролем версий. Долгоживущий хост держит одну сессию EDT на все команды.

19. EDT сливает изменения интерактивно

Изменения базы EDT переносит в проект через сравнение и объединение, конфликты решает человек в редакторе (109).

Ответ раннера. Для формата EDT слияния нет ни в одном режиме: выгрузка либо заменяет проект, либо отказывается.

Что раннер не делает намеренно