Добрый день.
Ситуация следующая:
Есть два замещающих объекта Case. Один находится в пакете для разработке. Второй - в пакете Custom. Возникла необходимость реализовать логику в casePage, затрагивающую поля из Case в пакете Custom. Но дилемма в том, что логика должна быть реализована в пакете для разработки.
Вопрос как перенести объект Case из Custom в пакет для разработки (слить два замещающих объекта), чтобы не затереть существующую логику, уже реализованную в Case пакета разработки?
Нравится
Добрый день, Игорь!
В данный момент времени, механизм автоматического слияния изменений в объектах из разных пакетов отсутствует. Есть механизм ручного переноса изменений, который мы рекомендуем использовать.
Во-первых, нужно проверить не нарушена ли у Вас иерархия пакетов. Пакет Custom должен быть последним в иерархии всегда. И по-хорошему наследоваться от всех других пакетов в системе и от пакета разработки, но это уже не обязательно.
Перед выполнением указанных действий обязательно выполните бекап БД.
Слияние необходимо выполнить для 2-х типов схем: EntitySchema и ClientUnitSchema
Рассмотрим слияние EntitySchema:
В объекте Case из пакета Custom добавлены кастомные колонки, которые Вы хотите перенести.
Открываем объект Case из пакета разработки на редактирование добавляем колонки, которые сейчас есть в объекте Case пакета Custom с такими же именами и соответствующими типами. Не закрывая дизайнер удаляем объект Case из пакета Custom и сразу сохраняем и публиуем объект Case, в который Вы переносили изменения.
Рассмотрим слияние ClientUnitSchema:
Сливать ClientUnitSchema намного сложнее, так как необходимо анализировать обе схемы и сливать их значение в одно. Для примера выполним сливание схемы ContactPageV2 из пакета Custom в схему ContactPageV2 из пакета разработки.
1.Открываем обе схемы в дизайнерах. Если посмотреть на содержимое схем, то можно заметить, что некоторые свойства объекта содержат значение (в данном случае diff). Пример на скриншоте "image2".
2. Дальше необходимо анализировать содержимое каждого элемента в diff-е.
3. Ищем совпадающие элементы по полям «opperation» и «name»
4.Анализируем значение полей свойства «values»:
- Если в новой версии такого поля нет, то добавляем
- Если в новой версии такое поле есть, то подменяем его значение
5. Если в схеме, в которую переносим данные, нет элементов с соответствующими полями «opperation» и «name», то переносим элемент целиком. Пример на скриншоте image3
6. Выполняем п.п. 3-5 для всех элементов объекта, который возвращает функция.
7. После переноса/слияния всех данных, схему из пакета Custom можно удалить.
Михаил, здравствуйте!
Спасибо за ответ!
Как раз таки слияние ClientUnitSchema не взывает затруднения.
А вот к EntitySchema есть вопросы. Не затрётся ли содержимое переносимых полей при реализации описанной схемы?
Добрый день, Игорь!
Описанный ранее метод слияния EntitySchema вполне рабочий и несколько раз сам его применял.
Если все делать согласно инструкции, то проблем быть не должно. Единственный совет, откройте данные объекты (который будете удалять и который будете изменять) в разных браузерах, так будет надежнее. Если у Вас есть предостережения, Вы можете протестировать на тестовой сборке.