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

[mazzy]

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

Цитата:

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

И журналов. И ордеров (заказов). И проводок (GeneralJournalAccountEntryEntity).

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

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

А как сейчас?

[trud]

Дублируют и добавляют V2, V3..

[fed]

Цитата:

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

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

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

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

А как сейчас?

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

[mazzy]

Цитата:

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

Дублируют и добавляют V2, V3..

Ахренеть! Тоже решение, конечно.

[mazzy]

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

Цитата:

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

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

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

[fed]

Цитата:

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

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



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

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

[trud]

Цитата:

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

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

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

Цитата:

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

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

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

[mazzy]

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

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

[mazzy]

Цитата:

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

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

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

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

[trud]

Цитата:

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

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

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

[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 и в связи с этим немного переформатировать код. Однако получается, что с т.з. глобальной компиляции - устаревание кода ошибок не влечет за собой. А вот непосредственный вызов... уже не возможен

[ax_mct]

https://docs.microsoft.com/en-us/dyn...ed/one-version

Цитата:

Backward compatibility covers binary and functional compatibility. Binary compatibility means that you can apply an update on any runtime environment without needing to recompile, reconfigure, or redeploy customizations. This also means that on a development environment at design time, X++ public and protected APIs and metadata are not modified or deleted. If Microsoft needs to break compatibility by removing obsolete APIs, it will be communicated 12 months in advance and follow a deprecation schedule. Functional compatibility is about user experience, all new experiences will be opt-in.

Backward compatibility does not include non-X++/metadata APIs. Microsoft reserves the right to update versions of any dependencies the product uses, as well as remove dependencies without early warning. Microsoft does not commit to maintain backwards compatibility of dependent software libraries unless expressly stated.

Пока вижу что в части функциональной совместимости речь только про UX. Я так думаю что если приучить к Runtime ошибкам то здесь то там время от времени то UX не меняется

[ax_mct]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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

[twilight]

У нас на проекте с помощью entity сделана интеграция с весами. В том числе создание заказов, если это необходимо, и разноска накладных. Так что там можно запрограммировать практически все, что угодно )

[ax_mct]

Цитата:

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

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

Цитата:

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

У нас на проекте с помощью entity сделана интеграция с весами. В том числе создание заказов, если это необходимо, и разноска накладных. Так что там можно запрограммировать практически все, что угодно )

Чуть в сторону от темы, но все же.
А есть отличие если бы мы тоже самое делали в типичной Staging table в AX?
Есть batch job, мы там можем "запрограммировать практически все, что угодно".

[twilight]

В Staging table данные надо как-то положить. Data entities как раз для этого. Дальше отличий особых нет.

[ax_mct]

Цитата:

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

В Staging table данные надо как-то положить. Data entities как раз для этого. Дальше отличий особых нет.

А чем отличается то как мы кладем в Staging table и как в Data entities?

[twilight]

Тем, что Data entities предоставляет определенный framework по настройке экспорта/импорта в различные форматы, мэппинг, логгирование, запуск по расписанию, объединение в проекты, права доступа и т. д. Это, по сути, удобный готовый инструмент по обмену данными со stage таблицами Аксапты и, в простых случаях, обмен stage с прод таблицами (для мастер данных).