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

[sukhanchik]

Цитата:

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

1. если хотим в дев / тест базу перенести данные из рабочей, то приходится в куче мест (в стандартном коде) перебивать идентификаторы, так как в базе с данными остается много мест, где связь идет по идентификатору таблицы, поля, в пакетных обработках и прочих местах ссылка идет по идентификатору класса. В номерных сериях по номеру EDT, в SysDataBaseLog ... в общем лучше не заглядывать. Т.е. как обычно новую концепцию внедрили, но в стандартном коде все не "причесали".

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

Из плюсов - какие-то незаконченные и заброшенные модификации - просто автоматически исчезают из приложения.
Из минусов - приходится периодически напрягаться в плане переноса - у всех же разное количество объектов в проектах. Однако это может быть облегчено тем, что перед обновлением - многие вещи (типа EDT / таблицы) могут вполне уехать на STAGE и жить "мертвым грузом" на PROD никому не мешая с одной стороны, а с другой стороны - сокращая количество объектов, которые приходится восстанавливать через XPO

[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шников объектов не поменяет значения в релейшнах. Ну... насколько я понял. Верно?