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

[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 ? Какой-то баг обходили ?

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

[sukhanchik]

Цитата:

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

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

Да, это я затупил - там нет констант. Почему-то был уверен, что там константы.

Константы я использовал в Relation-ах тогда, когда хотел вывести в параметры модуля внешний код для такой-то таблички. Ну, к примеру, "Внешний код спецификаций". Т.е. нужен лукап, который бы фильтровал по коду таблицы.

Но по факту - такие лукапы наверное удобнее делать через код и tablenum(), нежели прописывать в явном виде код таблицы в Relation. Хотя для стандартных таблиц - ID таблицы-то единый - поэтому в принципе критического ничего нет.

Вот, к примеру - таблица из стандартного функционала


А если открыть стандартную табличку AifEndpointActionValueMap - то там вообще страсти...