|
23.05.2021, 14:15 | #1 |
Участник
|
Есть одна проблема, которая всё усложняет -- расширение таблиц, то есть добавление в них полей. Вообще, я придумал как, но как говорит один бывший коллега "практика - критерий истины". Надо писать рабочий пример.
Последний раз редактировалось Lemming; 23.05.2021 в 14:18. |
|
23.05.2021, 14:21 | #2 |
Участник
|
Цитата:
ядро отвечает за join таблиц расширений. каждый плагин получает tableBase join tablePluginN этот способ категорически не работает с внешними генераторами отчетов и внешними потребителями данных. собственно из-за чего наследование таблиц в ax2012 и выпилили - майкрософт топил за Reporting Service вернее, внешние генераторы отчетов должны ожидать такого поведения от системы. Собственно так работают многие закрытые системы. добавлено: конечно же в системе где-то должна быть информация о плагинах, о том, какие таблицы какой плагин добавляет. эта информация должна быть доступна внешним системам. типа SysDicttionary в существующей аксапте, только намного богаче Последний раз редактировалось mazzy; 23.05.2021 в 14:32. |
|
23.05.2021, 14:42 | #3 |
Участник
|
Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?
|
|
23.05.2021, 17:35 | #4 |
Administrator
|
Цитата:
SalesTable SalesTable_RU (SalesTable_RU.SalesTable == SalesTable.RecId). Связь 1:1 или 1:0 (1 - SalesTable, 0 - SalesTable_RU) SalesTable_BR (SalesTable_BR.SalesTable == SalesTable.RecId) Связь 1:1 или 1:0 (1 - SalesTable, 0 - SalesTable_BR) А вот обратиться в стандартном коде к новой таблице естественно не получится. Тут уже нужен "хук", как говорит mazzy В D365FO сделали отдельный объект АОТа "Расширения таблиц" (также для форм) и дальше при билде все расширения "склеиваются" между собой и синхронизация добавляет все поля из всех расширений. При этом расширения (формально, по заявлению MS) могут линковаться при билде в абсолютно любой последовательности и нет возможности отследить их порядок (точнее MS оставляет за собой право пересмотреть порядок в любой момент времени) Из минусов - программист не имеет представление о конечном виде форм / таблиц. Т.е. форму, в которой куча расширений внесли те или иные изменения не увидеть в итоговом виде. Только если с нуля делать свою форму. Поэтому у расширений тоже есть ограничения по применению.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 23.05.2021 в 17:39. |
|
23.05.2021, 18:40 | #5 |
Участник
|
Цитата:
Цитата:
но в отсутствие плагинов сделали как смогли - неуправляемо захадкожено и совершенно спрятано-невидимо для внешних систем. в старых аксаптах пример псевдоплагинных таблиц InventTableModule (с большими оговорками) в ax2009 типичный пример псевдоплагинных таблиц - LedgerJournalTrans в ax2012 таких псевдоплагинных таблиц уже много, поскольку пришло много разработчиков со Scala. Особенно "удались" расширения для стран (PL, BR и др.) sukhanchik привел пример для SalesTable мой же любимый пример из ax2012 - это конечно базовая таблица unitOfMeasure и таблица-расширение unitOfMeasure_W, которая содержит 2 (два!) поля. Одно из которых является ссылкой на запись в базовой таблице. Таблица-расширение была явно создана человеком, который пришел из закрытых систем с плагинами. Но этот человек не обнаружил в Аксапте никаких механизмов, которые обслуживают такие таблицы. Мало того, эта таблица-расширение появилась до того, как в аксапте появился функционал наследования таблиц (наследование таблиц был настолько непродуманным механизмом, что его выпилили прям в следующем сервис-паке, но при этом оставили свойства для настройки этого долбанного наследования) в общем, unitOfMeasure_W - типичный образчик того, как расширяют таблицы в мире закрытых систем с плагинами. Последний раз редактировалось mazzy; 23.05.2021 в 18:43. |
|
|
За это сообщение автора поблагодарили: sukhanchik (4). |
23.05.2021, 23:21 | #6 |
Administrator
|
Верно, реализация - полное г... Но в качестве идеи подходит. Можно обратиться и к предыдущим версиям и посмотреть, как сказал mazzy - на тамошнюю реализацию (LedgerJournalTrans)
__________________
Возможно сделать все. Вопрос времени |
|
24.05.2021, 09:42 | #7 |
Участник
|
Цитата:
Если бы оставили все в одной таблице, то количество полей бы превысило пределы которые обрабатывает AOS по умолчанию, так же пустые денные забивали буферы на SQL Server (например в одной компании нужны только бразильские поля и там миллиард записей, в другой компании только польские и там тоже миллиард записей, а запросы обычно запрашивают данныетолько одной компании). Конкретно про UnitOfWork сказать не могу |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
24.05.2021, 11:14 | #8 |
Участник
|
Цитата:
Сообщение от belugin
В 2012 в рамках проекта OneGLS были объединены слои GLS для APAC, LATAM и EMEA в один. Чтобы можно было сделать Multinational у которого одна компания бразильская, другая - латвийская, например.
Если бы оставили все в одной таблице, то количество полей бы превысило пределы которые обрабатывает AOS по умолчанию, так же пустые денные забивали буферы на SQL Server (например в одной компании нужны только бразильские поля и там миллиард записей, в другой компании только польские и там тоже миллиард записей, а запросы обычно запрашивают данныетолько одной компании). Конкретно про UnitOfWork сказать не могу Если "количество полей бы превысило пределы которые обрабатывает AOS по умолчанию", то надо разбивать таблицу по количеству полей ПО связанности полей друг с другом (по смыслу). Т.е. надо было бы отрефакторить функционал. А сделали разбитие "по странам", полностью игнорируя как поля используются, как взаимодействуют. Типа в очередной раз Майкрософт решил свои технические проблемы за счет потребителей. Причем именно тех потребителей, которые и являются заинтересованным ядром ("у которого одна компания бразильская, другая - латвийская, например") Поэтому легенда так себе, фиговенькая. Особенно, если она правда. |
|