|
07.01.2018, 09:34 | #1 |
Модератор
|
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
07.01.2018, 22:30 | #2 |
Banned
|
Присоединяюсь к комментарию ниже. Система достигла такого уровня совершенства что программисты не нужны.
Цитата:
Fsaetre 1 day ago
Probably the one feature that has the most impact on user experience and process development since the release of AX7. Amazing. Надувные бассейны в каждый дом! Почувствуйте что море вам по колено! Ну вот есть у нас DEV/TEST/PROD. Пользователи добавили в PROD эти поля. Деплоймент этой таблицы из TEST на PROD - убиваем эти поля, разве нет? Фича тем не менее хорошая но в концепции когда DEV/TEST нет в принципе, а есть облачный PROD и только и кроме как таких изменений ничего не надо. И то по сути подменяет то что часто нужно через Document management. |
|
07.01.2018, 22:54 | #3 |
Участник
|
Этой это какой? Эти поля работают как обычный table extension, просто создается он в рантайме. Т.е. почему деплоймент таблици должен убивать поля в ее экстеншене?
|
|
07.01.2018, 23:15 | #4 |
Banned
|
Цитата:
Но пусть это Table1Ext таблица что связана по RecId с Table1. Предположим что она существует и в TEST и в PROD. То есть добавили одно такое поле, обновили TEST и имеем Table1Ext таблицу c полем Field1 и в TEST и в PROD. После этого пользователи добавили Field2 в PROD. Получается что ни при каких обстоятельствах мы не должны импортировать в PROD эту table extension так как версии могут отличаться в силу (прямого) UI программирования в PROD. Понятно что это конкретная таблица именно для UI расширений которую программист трогать не должен. Но это все равно неудобно для деплоймента и выравнивания инстансов так как изменения рождаются не на том конце. Другое дело что не проблема когда программирования как такового нет и нет цепочки деплоймента, а есть только такое псевдо-программирование на одном единственном PROD. |
|
08.01.2018, 10:31 | #5 |
Участник
|
Цитата:
|
|
08.01.2018, 15:06 | #6 |
Banned
|
Цитата:
Сообщение от skuull
Эээ, это не тот extension который просто левая табличка со связью 1 к 1 по RecId, это еще 1 поле в базе данных в той самое таблице, тут о них пишут для тех кто не в курсе. Деплоить в классическом смысле его невозможно потому что это код который создаеться в рантайме и когда вы создаете в UI FIeld1 в БД получите Field1_Custom. Из этогго следует - не создавайте поля которые заканчиваються на _Custom и будет вам счастье.
DEV и TEST об этом не знают. Переносим разработку с данной таблицей которая по сути имеет другую версию в PROD. В AX7 "умный" мерджинг и одаренная синхронизация с DB? Конфликтов не будет? Я не в курсе, просто интересно. |
|
08.01.2018, 23:33 | #7 |
Участник
|
Я сам не проверял и проверять не хочу, мне вообще вся эта фича не нравится. Но я не вижу принципиального отличия от ситуации где у вас в моделе А есть табличка Т1 и в моделе Б есть extension этой таблички Т2. Мы это деплоим в Прод. Потом удаляем на деве T2, меняем T1 и по забывчивости забываем задеплоить Б модель, а переносим только А. Что будет ? Наверняка все развалится, а может и нет.
|
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
Теги |
d365o |
|
|