Каков механизм апгрейда Data Entity в мажорных и минорных версиях современной аксапты?

[fed]

Цитата:

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

Выделил из соседней ветки

И еще. С удовольствием послушаю/почитаю как они решили вопрос с апгрейдом этих Data Entity на новые версии Аксапты.

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

А как сейчас?

Официальная точка зрения что сейчас апгрейда данных просто нету. Надо в первом ежемесячном релизе добавить новые поля. Потом в следующем ежемесячном релизе, добавить куда-то в синк скрипт, логику, которая один раз эти поля для старых записей обновит. Потом следующем ежемесячном релизе - добавить уникальные индексы по этим самым новым полям. Потом поменять логику в классах, так чтобы вынимала данные из новых полей и таблиц, вместо старых. Ну и тд. Официальное обоснование - надо апгрейдить PROD instance очень быстро и времени на запуск больших и толстых скриптов - нету.
Ну и по поводу data entity - по моему они просто создают на каждое изменение новую версию data entity. Типа CustCustomerV10

[mazzy]

А какой смысл от такого фасада, если он меняется при каждом чихе?

Цитата:

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

Официальное обоснование - надо апгрейдить PROD instance очень быстро и времени на запуск больших и толстых скриптов - нету.
Ну и по поводу data entity - по моему они просто создают на каждое изменение новую версию data entity. Типа CustCustomerV10

А для V1, V2 ... V9 гарантируют работоспособность в новой версии?

[fed]

Цитата:

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

А какой смысл от такого фасада, если он меняется при каждом чихе?



А для V1, V2 ... V9 гарантируют работоспособность в новой версии?

Не знаю. Вероятно они просто еще не подумали.Может они просто оставят старые entity ссылаться на устаревшие таблицы и поля, которые реально не обновляются.
Они там тоже в Микрософте работают в режиме "hand to mouth" - больше чем на один релиз не планируют. Типа это не бардак, а Agile...

[mazzy]

Со всей уверенностью могу сказать - думали.
в 2017 решения еще не было, но документ-обоснование вопросами к апрейду - был.

значит, сейчас не гарантируют работоспособность "старых" data entity. прикольно.
тогда нет никакого смысла их использовать - это не фасад, а всего лишь еще один транспортный уровень. примерно с такой же изменчивостью что и просто таблицы/классы.

[trud]

Цитата:

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

значит, сейчас не гарантируют работоспособность "старых" data entity. прикольно.

так а что понимается под словом работоспособность то. Что не выдается трассировок стека?
data entity используют отдельный от форм механизм для маппинга полей(метод defaultRow), т.е. вполне возможно что загружая что-то с помощью дата ентити ты получишь не то, что было было если бы поля вводились вручную

[ax_mct]

Цитата:

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

тогда нет никакого смысла их использовать - это не фасад, а всего лишь еще один транспортный уровень. примерно с такой же изменчивостью что и просто таблицы/классы.

Мне кажется что это эти Data Entity просто обычные Staging tables для обработки в batch jobs.
И ничего больше.

[EVGL]

Цитата:

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

Мне кажется что это эти Data Entity просто обычные Staging tables для обработки в batch jobs.
И ничего больше.

"И ничего больше" - ответ неполный. Важны расширяемые триггеры на самой entity для обработки сложных случаев. Я в одном таком триггере запрограммировал автоматическое рассопоставление проводок по клиенту при импорте отклоненных SEPA direct debits.

[trud]

Цитата:

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

А какой смысл от такого фасада, если он меняется при каждом чихе?

ты же сам написал в предыдущей теме - для владельца объекта это повышает шанс что ничего не сломается, т.е. будет меньше воплей - мы установили обновление и наша интеграция сломалась, так как она ожидала 10 полей, а пришло 11

Цитата:

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

А для V1, V2 ... V9 гарантируют работоспособность в новой версии?

Гарантрируется только бинарная совместимость т.е. обновление должно безболезненно устанавливаться и работать

[mazzy]

Цитата:

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

Гарантрируется только бинарная совместимость т.е. обновление должно безболезненно устанавливаться и работать

э-э-э... не надо "осетрины второй свежести". пожалуйста.

так гарантируется, что data entity прошлых версий будут работать так же как и раньше в новой версии или нет?
другими словами, код, который использует V1, продолжит работать корректно, когда появляется V2?

[Vadik]

Цитата:

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

другими словами, код, который использует V1, продолжит работать корректно, когда появляется V2?

Это декларируется, но не всегда работает Как минимум в случае доступа через OData если создавалось расширение и Public name перенесли на "новую" версию

[sukhanchik]

Цитата:

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

э-э-э... не надо "осетрины второй свежести". пожалуйста.

так гарантируется, что data entity прошлых версий будут работать так же как и раньше в новой версии или нет?
другими словами, код, который использует V1, продолжит работать корректно, когда появляется V2?

У меня была такая ситуация. Сделал я импорт номенклатур и создавал номенклатуры в коде, используя EcoRes-чего-то там Entity. Было это еще до PU20.
С выходом PU20 добавили к этой Entity - EntityV2 (ну кстати аналогично появились обновленные версии Entity по контрагентам). Мы обновились на PU20 и вроде как все было нормально, компиляция проходила и т.д.
Но... потом выяснилась интересная ситуация. Методы классов, сопутствующих этой Entity были помечены атрибутом [Obsolete], а код, который по идее должен был работать - валился в Runtime-ошибку, мол нельзя вызывать метод, объявленный как obsolete.
Решение было простое (конечно после анализа ситуации) - заменить в коде вызов Entity и сопутствующих классов - на V2 и в связи с этим немного переформатировать код. Однако получается, что с т.з. глобальной компиляции - устаревание кода ошибок не влечет за собой. А вот непосредственный вызов... уже не возможен