Выравнивание идентификаторов (Prod --> Test --> Dev и Prod --> Stage) в Axapta 2012 R3

[Logger]

Цитата:

Сообщение от sukhanchik

DEV / TEST базу обновляем данными с рабочей. А приложение обновляем тоже с рабочей (или со STAGE - разницы нет).
Дальше даём разработчикам условно неделю-две, чтобы перенести незаконченные модификации с DEV_OLD.

Спасибо. Вполне рабочий вариант. И много где используется.
Но мне теперь ближе свое изобретение. Наверно потому что свое. И потому что экономит время разработчиков.

[sukhanchik]

Цитата:

Сообщение от Logger

И потому что экономит время разработчиков.

Вот это вот утверждение сильно зависит от компании. Потому что идентификаторы объектов могут храниться в большом количестве таблиц и в большом количестве записей. Перебить все данные в условном SysDataBaseLog - это явно небыстро.
Перебить все данные, где хранится контейнер с сохраненным запросом (Query) - тоже небыстро. Это только навскидку я вспомнил - про места хранения ID-шников.
В итоге получается, что преобразование базы - это долго, а если этого не делать - то скопированная база будет некорректная с т.з. данных прода. Поэтому да, экономия времени разработчиков есть в той части, что им не приходится перетаскивать объекты. Однако я бы конечно предпочёл бы полноценную копию БД - т.к. на ней гораздо корректнее тестировать. Я к тому, что экономя время разработчика - нельзя забывать о времени консультанта. Если его время увеличивается - то это в общем случае не ведет к общей экономии времени разработки.

А компания компании рознь - кто-то может организовать несколько индивидуальных виртуалок с копией рабочей БД, а у кого только бекап 3 дня делаться будет. И в условиях ограниченности возможностей тестирования - конечно выбираешь такой подход, который бы лучше подходил под реалии.

А идея интересная, спасибо!

[Logger]

Цитата:

Сообщение от sukhanchik

Вот это вот утверждение сильно зависит от компании. Потому что идентификаторы объектов могут храниться в большом количестве таблиц и в большом количестве записей.

Ну вот я и исхожу из того, что время на обработку идентификаторов в базе модели будет меньше чем перебивка в бизнес базе. Плюс если делать инкрементную обработку (только по объектам созданным с прошлого переноса) то еще быстрее.

Насчет Query не понял вашу мысль. Вы имеет в виду что бинарные объекты могут в себе содержать ссылки по идентификаторам и их тоже надо обрабатывать ? Если они хранятся в бинарном виде в базе с бизнесданными (SysLastValue, Batch.Parameters, etc) то тем лучше для нас - нам не придется их трогать. А если в модели, то это может быть проблемой. Придется пересоздать / обновить. Но с таким примером я пока не сталкивался.

Цитата:

Сообщение от sukhanchik

Перебить все данные в условном SysDataBaseLog - это явно небыстро.

Да! Так мы и не будем этого делать при предлагаемом подходе. Profit !

[sukhanchik]

Цитата:

Сообщение от Logger

Насчет Query не понял вашу мысль. Вы имеет в виду что бинарные объекты могут в себе содержать ссылки по идентификаторам и их тоже надо обрабатывать ? Если они хранятся в бинарном виде в базе с бизнесданными (SysLastValue, Batch.Parameters, etc) то тем лучше для нас - нам не придется их трогать.

Да, я имел в виду, что Query.pack() хранится в бинарном виде с бизнес-данными и содержит в себе ID таблиц и полей.
Да, их можно не трогать, но тогда мы не сможем (условно на DEV) увидеть распакованные эти бинарные данные. Безусловно, конкретно для Batch / SysLastValue / SysDataBaseLog эта информация может быть и не нужна, но теоретически могут быть ситуации, когда для целей разработки эта информация может понадобиться. Собственно именно поэтому я ратую за полную копию данных и приложения - в этом случае гарантированно получается полная копия рабочей среды и любые какие-бы ни были задачи для разработчиков - они всегда заведомо могут быть реализованы на данных DEV-системы в условиях, максимально приближённых к реальности

[Logger]

Цитата:

Сообщение от sukhanchik

Да, их можно не трогать, но тогда мы не сможем (условно на DEV) увидеть распакованные эти бинарные данные.

Мне кажется здесь какое то недопонимание.
Мы не сможем их увидеть распакованными на DEV если идентификаторы в DEV модели отличаются от идентификаторов Prod-модели.
Так я с этого и начал обсуждение - чтобы выравнивать идентификаторы DEV и PROD моделей. Если их выровнять как я предложил то и проблем с распаковкой не будет.

[sukhanchik]

Цитата:

Сообщение от Logger

Мне кажется здесь какое то недопонимание.
Мы не сможем их увидеть распакованными на DEV если идентификаторы в DEV модели отличаются от идентификаторов Prod-модели.
Так я с этого и начал обсуждение - чтобы выравнивать идентификаторы DEV и PROD моделей. Если их выровнять как я предложил то и проблем с распаковкой не будет.

А... я понял... Т.е. мы обновляем БД PROD-> DEV, а ID-шники меняем в DEV_model на "продовские"

Если так - то всё ок. Действительно у меня было недопонимание.

Единственное что в таком случае интересно... так это ситуация типа внешних кодов ExtCode*-таблицы, когда в релейшне прописывается код таблицы. Я то в таких случаях как делал.... Писал код на DEV, затем переносил на STAGE и там менял ID-шники таблицы в Relation. Затем STAGE "уезжал" на PROD, а когда DEV (приложение + БД) заменялось полностью с PROD-а - то само собой - эта проблема меня уже не беспокоила.

В Вашем скрипте - эта ситуация точно не учтена и изменение IDшников объектов не поменяет значения в релейшнах. Ну... насколько я понял. Верно?

[Logger]

Цитата:

Сообщение от sukhanchik

Т.е. мы обновляем БД PROD-> DEV, а ID-шники меняем в DEV_model на "продовские"

Да, именно так.

Цитата:

Сообщение от sukhanchik

Единственное что в таком случае интересно... так это ситуация типа внешних кодов ExtCode*-таблицы, когда в релейшне прописывается код таблицы. Я то в таких случаях как делал.... Писал код на DEV, затем переносил на STAGE и там менял ID-шники таблицы в Relation. Затем STAGE "уезжал" на PROD, а когда DEV (приложение + БД) заменялось полностью с PROD-а - то само собой - эта проблема меня уже не беспокоила.
...
В Вашем скрипте - эта ситуация точно не учтена и изменение IDшников объектов не поменяет значения в релейшнах. Ну... насколько я понял. Верно?

Если там использован тип связи "Field fixed" или "Related field fixed" то, конечно, ничего не поменяется и будет проблема. Тут вы правы.

Но, если связь сделана как ExtCode* табличках (а там использован Normal relation, просто связь идет на фиктивное поле TableId связанной таблички) то думаю, что все будет хорошо. Надо будет протестировать конечно. Но должно быть норм.
А зачем вы явно константу ставили вместо ссылки на поле TableId ? Какой-то баг обходили ?

Скрипт на самом деле не совсем мой. Я просто взял стандартный код и исправил в нем ошибки. Но конечно сильно все перепахал. Так что как бы и мой теперь.