Автоматическое сравнение-объединение с cf (Пакетный режим)
Доброго времени суток. Задача не боевая, просто изучаю возможности платформы.
Идея: инкрементально догружать изменения в основную кф.
Суть вопроса: если подготовить cf файл, содержащий только изменения относительно основной кф, то при открытии окна сравнения по умолчанию накладывается такая логика:
1. то что есть в кф, но нет в файле - остается;
2. то что есть в кф и есть в файле - берется из файла;
3. то что отсутствует в кф, но есть в файле - берется из файла.
Меня устраивает такая логика, но при попытке мержевания в пакете, требуется параметр-указатель на xml файл настроек mergesetting. Данный файл можно получить только при кастомном объединении и в данном случае в нем нет необходимости. Есть ли какой то флаг, которым можно сбросить выбор данного файла?
Моя команда:
"СТАРТЕР или ТОЛСТЫЙ КЛИЕНТ" DESIGNER /F "БАЗА" /MergeCfg "CF ФАЙЛ" -Settings "ФАЙЛ НАСТРОЕК" -force /UpdateDBCfg
Идея: инкрементально догружать изменения в основную кф.
Суть вопроса: если подготовить cf файл, содержащий только изменения относительно основной кф, то при открытии окна сравнения по умолчанию накладывается такая логика:
1. то что есть в кф, но нет в файле - остается;
2. то что есть в кф и есть в файле - берется из файла;
3. то что отсутствует в кф, но есть в файле - берется из файла.
Меня устраивает такая логика, но при попытке мержевания в пакете, требуется параметр-указатель на xml файл настроек mergesetting. Данный файл можно получить только при кастомном объединении и в данном случае в нем нет необходимости. Есть ли какой то флаг, которым можно сбросить выбор данного файла?
Моя команда:
"СТАРТЕР или ТОЛСТЫЙ КЛИЕНТ" DESIGNER /F "БАЗА" /MergeCfg "CF ФАЙЛ" -Settings "ФАЙЛ НАСТРОЕК" -force /UpdateDBCfg
По теме из базы знаний
Найденные решения
(1) В общем разобрался по своей гипотетической задачке. Файл mergesetting формируется и становится доступным для выгрузки, если мы изменяем стандартные настройки объединения (даже если просто зашли в настройки объединения какого либо модуля и приняли изначально созданные правила). В таком случае модифицированные правила объектов формируются в теге Objects, из-за него и создается данный файл настроек. Но до модификации правил уже существовали настройки примерно такого вида:
<?xml version="1.0" encoding="UTF-8"?>
<Settings xmlns="http://v8.1c.ru/8.3/config/merge/settings" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2" platformVersion="8.3.11">
<MainConfiguration>
<Name>Конфиг</Name>
</MainConfiguration>
<SecondConfiguration>
<Name>Конфиг</Name>
</SecondConfiguration>
<Parameters>
<ConfigurationsRelation>ConfigurationsNotRelated</Configurat
<AllowMainConfigurationObjectDeletion>false</AllowMainConfig
<CopyObjectsMode>false</CopyObjectsMode>
</Parameters>
</Settings>
Это основная логика мержевания образующая общие правила, в этом случае файл настроек не создается.
При объединении в пакете команд файл настроек является обязательным параметром (хз почему), но парсить структуры измененных объектов для наполнения тега Objects не обязательно, достаточно указать шапку и произойдет объединение по умолчанию (старые остаются, новые создаются, измененные изменяются)
<?xml version="1.0" encoding="UTF-8"?>
<Settings xmlns="http://v8.1c.ru/8.3/config/merge/settings" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2" platformVersion="8.3.11">
<MainConfiguration>
<Name>Конфиг</Name>
</MainConfiguration>
<SecondConfiguration>
<Name>Конфиг</Name>
</SecondConfiguration>
<Parameters>
<ConfigurationsRelation>ConfigurationsNotRelated</Configurat
<AllowMainConfigurationObjectDeletion>false</AllowMainConfig
<CopyObjectsMode>false</CopyObjectsMode>
</Parameters>
</Settings>
Это основная логика мержевания образующая общие правила, в этом случае файл настроек не создается.
При объединении в пакете команд файл настроек является обязательным параметром (хз почему), но парсить структуры измененных объектов для наполнения тега Objects не обязательно, достаточно указать шапку и произойдет объединение по умолчанию (старые остаются, новые создаются, измененные изменяются)
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) То ли я где то неверно выразился, то ли чего то не понял в ссылках. Я уже нахватался этой инфы. Но из всего что я впитал, ощущение, что для автоматического наката изменений мне нужно также генерить сам этот xml-ник, ибо без его указания выскакивает ошибка пустого параметра.
Мой вопрос - есть ли команда, которая будет соответствовать объединению по умолчанию, по сценарию описанному выше (для которого не нужен файл настроек)
Мой вопрос - есть ли команда, которая будет соответствовать объединению по умолчанию, по сценарию описанному выше (для которого не нужен файл настроек)
(1) В общем разобрался по своей гипотетической задачке. Файл mergesetting формируется и становится доступным для выгрузки, если мы изменяем стандартные настройки объединения (даже если просто зашли в настройки объединения какого либо модуля и приняли изначально созданные правила). В таком случае модифицированные правила объектов формируются в теге Objects, из-за него и создается данный файл настроек. Но до модификации правил уже существовали настройки примерно такого вида:
<?xml version="1.0" encoding="UTF-8"?>
<Settings xmlns="http://v8.1c.ru/8.3/config/merge/settings" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2" platformVersion="8.3.11">
<MainConfiguration>
<Name>Конфиг</Name>
</MainConfiguration>
<SecondConfiguration>
<Name>Конфиг</Name>
</SecondConfiguration>
<Parameters>
<ConfigurationsRelation>ConfigurationsNotRelated</Configurat
<AllowMainConfigurationObjectDeletion>false</AllowMainConfig
<CopyObjectsMode>false</CopyObjectsMode>
</Parameters>
</Settings>
Это основная логика мержевания образующая общие правила, в этом случае файл настроек не создается.
При объединении в пакете команд файл настроек является обязательным параметром (хз почему), но парсить структуры измененных объектов для наполнения тега Objects не обязательно, достаточно указать шапку и произойдет объединение по умолчанию (старые остаются, новые создаются, измененные изменяются)
<?xml version="1.0" encoding="UTF-8"?>
<Settings xmlns="http://v8.1c.ru/8.3/config/merge/settings" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2" platformVersion="8.3.11">
<MainConfiguration>
<Name>Конфиг</Name>
</MainConfiguration>
<SecondConfiguration>
<Name>Конфиг</Name>
</SecondConfiguration>
<Parameters>
<ConfigurationsRelation>ConfigurationsNotRelated</Configurat
<AllowMainConfigurationObjectDeletion>false</AllowMainConfig
<CopyObjectsMode>false</CopyObjectsMode>
</Parameters>
</Settings>
Это основная логика мержевания образующая общие правила, в этом случае файл настроек не создается.
При объединении в пакете команд файл настроек является обязательным параметром (хз почему), но парсить структуры измененных объектов для наполнения тега Objects не обязательно, достаточно указать шапку и произойдет объединение по умолчанию (старые остаются, новые создаются, измененные изменяются)
для объединения конфигураций с использованием файла настроек мы добавили новый параметр командной строки MergeCfg
обязательный параметр Settings со своим параметром <имя файла настроек>;
Если вы сами готовите файл cf, то почему бы не подготовить к нему и файл настроек объединения?
Другой момент: как можно быть уверенным, что конфигурация, на которую накатывается обновление, не изменена и обновление произойдёт в штатном режиме? Или это ваша внутренняя конфа? Может лучше начать делать поставки?
(8) Так, я объясню. Это выдуманная задача, дабы понять, насколько возможен частичный обмен кф на загрузку и выгрузку (с выгрузкой все гораздо проще). Гипотетически мы ведем коллективную разработку и используем децентрализованный контроллинг версии, но работаем с конфигуратором. Для нас необходимо развернуть рабочее место (в моем варианте сборщик готовит актуальную конфигурацию из файлов), далее предполагается лишь выгружать измененные объекты и проверять наличие обновлений искомой ветки проекта. Cfu банально более ресурсозатратный процесс, так как имеет собственный механизм поиска отличий, соответственно для его подготовки нужно иметь 2 полноценные конфигурации, по которым будет произведено сравнение, это усложняет сборочную линию. Здесь же перед автоматическим обновлением можно сохранить измененные строки configdumpinfo, и запустить пакет, который выгружает рабочую конфигурацию, накатывает все "релизные" cf, апдейтит базу, замещает изначальный файл configdumpinfo, и далее только в конце нужно сравниться с выгруженной конфой. Фактически при последующем ручном мержевании у нас есть все водные, чтобы определить наличие дважды измененных объектов, при этом мы автоматом накатились на сколь угодно итераций изменений.
(11) Даже больше скажу, для ручной проверки конфликтов можно предварительно и не выгружать целиком конфу, а также выкинуть измененные объекты на сервер и получить cf только с изменениями относительно изначальной конфы, что полностью нивелирует какие либо полные выгрузки/загрузки
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот