Различие Id объектов в Приложении разработки и рабочем

[Ivanhoe]

Цитата:

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

Если накатите на разработческую базу рабочее приложение целиком, то в разработческой базе может слететь часть данных (но это не должно быть критичным, и то проблема решается).

Можно по-подробнее, как проблема решается?

Цитата:

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

Единственная возможная проблема может возникнуть только если вы захотите восстановить рабочую базу на девелоперском приложении (или наоборот). Тут могут быть проблемы с синхронизацией и слететь некоторые данные.

Обоим: Почему потеря данных не будет критичной? Мне кажется очень удобно иметь возможность в любой момент восстановить рабочую БД на тест или дев для анализа ошибок и проч.

[oip]

Цитата:

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

Если программировать правильно.

Сергей, а приведи какой-нибудь более-менее реальный пример, когда отличие в айдишниках хоть как-то повлияет на функционал и работоспособность системы? Мне в голову приходят только совсем уж клинические вещи.

Цитата:

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

Обоим: Почему потеря данных не будет критичной? Мне кажется очень удобно иметь возможность в любой момент восстановить рабочую БД на тест или дев для анализа ошибок и проч.

Например, у нас для "иметь возможность в любой момент восстановить рабочую БД на тест или дев для анализа ошибок" используется полностью отдельное приложение (в него периодически копируется рабочее). Практически "песочница". Там и мы что-то проверить-проанализировать можем, и пользователи могут поиграть немного.

[mazzy]

Цитата:

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

Сергей, а приведи какой-нибудь более-менее реальный пример, когда отличие в айдишниках хоть как-то повлияет на функционал и работоспособность системы? Мне в голову приходят только совсем уж клинические вещи.

1. Добавление складской аналитики.
В девелоперской базе проводили тестовые добавления, в результате финальный вариант складской аналитики один FieldID. Аналитику настраивают, проверяют. Все работает.

Затем проект переносят (без сохранения ID) в рабочую базу. FieldID у новой складской аналитики другой. Но этого не замечают и Без тени сомнения переносят настройки. Настройка складской аналитики основана на том, что в базе хранятся FieldID, поэтому все настройки сьезжают и не работают.
===================

2. Изменение складской аналитики
В девелоперской добавили складскую аналитику и руками добавили складскую аналитику в рабочую (FieldID разные). В рабочей настроили, работают. InventDim заполняется значениями для новой аналитики.

Потом какой-нибудь "негодяй" решает перенести InventDim проектом (с сохранением ID). При синхронизации поле со старым ID удаляется и создается поле с таким же именем, но другим ID. Естественно только что созданное поле будет пустым. InventDim будет невалидным.

====================
3. Полный список проблемных мест (с точки зрения ID) в стандартном функционале ax4.0 (всего потенциально опасных 1122 места, из них 139 в таблицах)

См. таблицу в аттаче.

Технология обнаружения проблемных мест в любой базе:
берете системные типы FieldID и TableID, смотрите по перекрестным ссылкам где они используются. Оставляете только те записи тип которых = Write. Убираете методы \modifiedField, \validateField, \Unpack, \Lookup

[mazzy]

См. также рекомендации здесь
palleagermark: Dealing with changed table or field id's

[oip]

Цитата:

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

и Без тени сомнения переносят настройки. Настройка складской аналитики основана на том, что в базе хранятся FieldID, поэтому все настройки сьезжают и не работают.

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

Цитата:

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

Потом какой-нибудь "негодяй" решает перенести InventDim проектом (с сохранением ID)

Опять-таки, это понятно и выше написано, что если айдишники разные, то с сохранением айдишников переносить проекты нельзя. Глеб это написал в первом же сообщении.

Эти все примеры не о "правильности" программирования говорят, а о правильности процедуры настройки приложения (в первом случае) и правильности процедуры его обновления (во втором).

[mazzy]

Цитата:

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

Эти все примеры не о "правильности" программирования говорят, а о правильности процедуры настройки приложения (в первом случае) и правильности процедуры его обновления (во втором).

А неправильность программирования проявляется:
1. в наличии констант-идентификаторов в коде.
2. в предположении, что идентификаторы никогда не изменяются (даже системные)
3. в наличии вызовов объектов по идентификатору объекта (сколько раз видел)
4. в наличии создания объектов по идентификатору объекта (сколько раз видел)
5. в неграмотном юзании Dict-классов
6. в неправильной обработке ошибок в паттерне pack/unpack
7. в очень неграмотном юзании кэша (в него зачастую записывают идентификаторы)
8. в неграмотном юзании параметров пакетных заданий
9. и т.п.

[glibs]

Цитата:

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

...
Мне кажется очень удобно иметь возможность в любой момент восстановить рабочую БД на тест или дев для анализа ошибок и проч.
...

Если размер БД больше 5-10 ГБ, то мне такой процесс удобным уже не кажется. Долговато.

Когда речь идет о работе одного-двух разработчиков, то можно договориться о том, чтобы регулярно тереть разработческое приложение продуктивным. Я обычно так стараюсь делать. Хотя все еще сильно зависит от культуры разработки и характера модификаций (если строится что-то огромное и фундаментальное, то оно может долго зависнуть в процессе разработки). А если разработки по моим меркам большие, то бью их на как можно более мелкие и несложно тестируемые атомарные куски. ИД объектов расходятся незначительно при таком подходе, обычно. И совсем ненадолго.

Когда речь идет о большом коллективе разработчиков и серьезном подковыривании стандартного кода (или своего, но у всех популярного), а еще хуже если и о параллельных процессах аналогичного рода, то такой вариант реализовать трудно. В таких случаях даже переносить тяжело, т.к. вполне возможно, что в том объекте, в котором ты что-то дописал, кто-то другой сейчас ковыряется, и этот объект даже не компилируется. Мне кажется, что описанная вами проблема может серьезно стоять только в такого рода случаях.