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

[Evgeniy2020]

Здравствуйте,

Подскажите пожайлуста, вопрос по различию Id объектов в рабочем приложении и девелоперском.

Команда разработчиков меняет объекты и добавляет новые при этом
не только в девелоперское приложение а иногда в рабочее. Потом переносит объекты из рабочего в девелоперское (это конечно нарушение Best Practice)

а чем в последствии чревато - различие Id объектов таблиц, полей.. в приложениях?

[ZVV]

Цитата:

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

Здравствуйте,

Подскажите пожайлуста, вопрос по различию Id объектов в рабочем приложении и девелоперском.

Команда разработчиков меняет объекты и добавляет новые при этом
не только в девелоперское приложение а иногда в рабочее. Потом переносит объекты из рабочего в девелоперское (это конечно нарушение Best Practice)

а чем в последствии чревато - различие Id объектов таблиц, полей.. в приложениях?

- Полетят ссылки на таблицы, реализованные посредством TableIdRef+RecIdRef, если такие такие добавлялись на ваши новые таблицы. Такое есть например в Адресах, SpecTrans и др.. Полный список можно вычислить отсмотрев перекрёстные ссылки на системный EDT "tableId"
- Полетят ссылки на "ваши" поля в настройках обновлений "шапка-строки", например в таблицах Sales\PurchTable2LineParameters
- вероятно что-то ещё, больше навскидку ничего в голову не пришло

[glibs]

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

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

[oip]

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

[mazzy]

Цитата:

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

Вообще в данной ситуации ничего плохого нет.

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

Цитата:

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

Никаких проблем нет. Ничем не чревато.

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

[Ivanhoe]

Цитата:

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

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

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

Цитата:

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

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

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

[glibs]

Проверка аблиц с исправлением ошибок в SQL администрировании в периодических операциях модуля Администрирование. От EVGL первый раз услышал давно. Искать тяжело ссылку.

В 3.0 не работало, если ID таблицы не изменился, а ID поля менялся. Если менялись одновременно, то работало.

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

В 5.0 все работает. Как вариант можно попытаться перенести код из 5.0 в 4.0. Сам не пробовал, это гипотеза.

[oip]

Цитата:

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

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

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

Цитата:

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

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

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

[glibs]

Цитата:

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

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

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

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

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

[gl00mie]

Цитата:

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

Переносить нужно модификации без сохранения ИД объектов. Ни в коем случае не подкладывать приложение (слой) целиком.

"Ни в коем случае" - это почти как «квантор общности» "никогда"; обоснуйте

Цитата:

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

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

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

[glibs]

Цитата:

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

...
обоснуйте
...

Просто опыт.

Цитата:

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

...
Если переносить с сохранением идентификаторов
...

Как можно приложение целиком переносить с сохранением идентификаторов или без такового?

[sukhanchik]

Самая большая грабля - наличие id объектов в БД. Как правило - это TableID. Если TableId - относится к стандартной таблице (ну или к той, у которой на дев и ворк id совпадают) - то проблем нет. А вот если он относится к своей таблице (объекту), по которой id не совпадают - то получится, что восстановление копии БД на дев будет невозможным без потери логики.
Плюс - код таблицы (конкретное число) может встречаться еще на релейшнах. Т.е. при изменении кода таблицы - соотв слетят лукапы и прочие прелести релейшна.

А так - различие id объектов влияет только на синхронизацию. Но как сказал glibs - эта проблема решается через \Администрирование\Периодические операции\Администрирование SQL\Проверка\Проверка-Синхронизация.
По поводу версии Аксапты - скажу так. Независимо от версии (3.0, 4.0) проверка работает (со всеми снятыми галками), если до проверки потереть данные в табличке SQLDictionary (главное при этом не выходить из Аксапты), после чего запускать проверку.

Поэтому - если "программировать правильно" (с), mazzy, т.е. никогда не завязываться на код объекта (как следствие - никогда не использовать связку TableId, RecId) - то проблем не будет.

Однако, у вас может быть другая проблема, не связанная с id-шником. После переноса модификаций через XPO вы запускаете глобальную компиляцию?
Компилируя только свой проект - вы рискуете получить ошибку выполнения кода, если в системе имеется некомпилированный наследник модифицированного класса, (например, который не вошел в проект).

И еще есть грабли, связанные с разными id-шниками. Если вы занимаетесь поддержкой уже работающего приложения, то вам может быть удобно иметь построенные перекрестные ссылки на рабочей БД. Но строить их может быть удобнее не на рабочей БД (дабы не нагружать сервера). Соответственно, построить ссылки на копии рабочей с последующим переносом таблиц XRef* на рабочую у вас не получится

[Ivanhoe]

Из моего опыта:
На этапе проектирования / опытной удобно иметь возможность быстро скопировать рабочую БД в тестовую / разработческую. Как правило на этом этапе размер БД - максимум десятки ГБ, ни на одном проекте это не было проблемой. Бэкап / рестор занимает минут 10 - это нормально.
Так уж мне везло, что только на одном проекте был один разработчик, в остальных случаях - целая команда.

Отсюда родились правила:
1. перенос проектов только с ID элементов (возможность переноса БД).
2. перенос только со сравнением (исключение переноса "чужих" доработок).
3. обязательная инкрементная компиляция всех классов (если родитель не вошел в проект, его нужно найти и откомпилировать).
4. периодическая очистка локального кеша пользователей (как ручная, так и принудительная, используя возможности ОС).

Пока писал, родился вопрос: а настройки прав доступа хранятся с привязкой к ID? при их переносе проблем не будет, если ID разные?

[sukhanchik]

Цитата:

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

Пока писал, родился вопрос: а настройки прав доступа хранятся с привязкой к ID? при их переносе проблем не будет, если ID разные?

Конечно с привязкой к ID - как я забыл-то. Так что если ID расходятся - то о функциональности переноса прав можно забыть

[gl00mie]

Цитата:

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

Цитата:

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

Переносить нужно модификации без сохранения ИД объектов. Ни в коем случае не подкладывать приложение (слой) целиком.

Просто опыт.

Аналогично, есть в т.ч. многолетний успешный опыт "подкладывания слоя целиком" Так почему же все-таки "ни в коем случае"?..

Цитата:

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

Как можно приложение целиком переносить с сохранением идентификаторов или без такового?

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

[oip]

Цитата:

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

Пока писал, родился вопрос: а настройки прав доступа хранятся с привязкой к ID? при их переносе проблем не будет, если ID разные?

Будет. И настройки пользователя (те, что в СисЛастВэлью) тоже слетят.

Цитата:

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

Аналогично, есть в т.ч. многолетний успешный опыт "подкладывания слоя целиком" Так почему же все-таки "ни в коем случае"?..

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

А так да, мы тоже слоем перетаскиваем. С девелоперского на тестовое - проектами, с тестового на рабочее - слоем.

[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. и т.п.