kurthatlevik: Great stuff on the D365 roadmap

[skuull]

Цитата:

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

Ну вот есть у нас DEV/TEST/PROD. Пользователи добавили в PROD эти поля.
Деплоймент этой таблицы из TEST на PROD - убиваем эти поля, разве нет?

Этой это какой? Эти поля работают как обычный table extension, просто создается он в рантайме. Т.е. почему деплоймент таблици должен убивать поля в ее экстеншене?

[ax_mct]

Цитата:

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

Этой это какой? Эти поля работают как обычный table extension, просто создается он в рантайме. Т.е. почему деплоймент таблици должен убивать поля в ее экстеншене?

Ага, справедливо

Но пусть это Table1Ext таблица что связана по RecId с Table1.
Предположим что она существует и в TEST и в PROD.
То есть добавили одно такое поле, обновили TEST и имеем Table1Ext таблицу c полем Field1 и в TEST и в PROD.
После этого пользователи добавили Field2 в PROD.

Получается что ни при каких обстоятельствах мы не должны импортировать в PROD эту table extension так как версии могут отличаться в силу (прямого) UI программирования в PROD.
Понятно что это конкретная таблица именно для UI расширений которую программист трогать не должен. Но это все равно неудобно для деплоймента и выравнивания инстансов так как изменения рождаются не на том конце.

Другое дело что не проблема когда программирования как такового нет и нет цепочки деплоймента, а есть только такое псевдо-программирование на одном единственном PROD.

[skuull]

Цитата:

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

Ага, справедливо

Но пусть это Table1Ext таблица что связана по RecId с Table1.

Эээ, это не тот extension который просто левая табличка со связью 1 к 1 по RecId, это еще 1 поле в базе данных в той самое таблице, тут о них пишут для тех кто не в курсе. Деплоить в классическом смысле его невозможно потому что это код который создаеться в рантайме и когда вы создаете в UI FIeld1 в БД получите Field1_Custom. Из этогго следует - не создавайте поля которые заканчиваються на _Custom и будет вам счастье.

[ax_mct]

Цитата:

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

Эээ, это не тот extension который просто левая табличка со связью 1 к 1 по RecId, это еще 1 поле в базе данных в той самое таблице, тут о них пишут для тех кто не в курсе. Деплоить в классическом смысле его невозможно потому что это код который создаеться в рантайме и когда вы создаете в UI FIeld1 в БД получите Field1_Custom. Из этогго следует - не создавайте поля которые заканчиваються на _Custom и будет вам счастье.

Ну вот в некой таблице прямо на PROD появляется Field1_Custom.
DEV и TEST об этом не знают. Переносим разработку с данной таблицей которая по сути имеет другую версию в PROD.
В AX7 "умный" мерджинг и одаренная синхронизация с DB? Конфликтов не будет?
Я не в курсе, просто интересно.

[skuull]

Цитата:

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

В AX7 "умный" мерджинг и одаренная синхронизация с DB? Конфликтов не будет?
Я не в курсе, просто интересно.

Я сам не проверял и проверять не хочу, мне вообще вся эта фича не нравится. Но я не вижу принципиального отличия от ситуации где у вас в моделе А есть табличка Т1 и в моделе Б есть extension этой таблички Т2. Мы это деплоим в Прод. Потом удаляем на деве T2, меняем T1 и по забывчивости забываем задеплоить Б модель, а переносим только А. Что будет ? Наверняка все развалится, а может и нет.