Как вы думаете: смог бы Линус Торвальдс в одиночку за 20 лет полностью повторить Асапту версии 3.0?

[Lemming]

Цитата:

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

1.
Легко. Изначально закрытая система с плагинами.

Есть одна проблема, которая всё усложняет -- расширение таблиц, то есть добавление в них полей. Вообще, я придумал как, но как говорит один бывший коллега "практика - критерий истины". Надо писать рабочий пример.

[mazzy]

Цитата:

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

Есть одна проблема, которая всё усложняет -- расширение таблиц, то есть добавление в них полей. Вообще, я придумал как, но как говорит один бывший коллега "практика - каритерий истины". Надо писать рабочий пример.

легко. наследование таблиц, которое вводили в ax2012, это на самом деле расширение таблиц.

ядро отвечает за join таблиц расширений.
каждый плагин получает tableBase join tablePluginN

этот способ категорически не работает с внешними генераторами отчетов и внешними потребителями данных. собственно из-за чего наследование таблиц в ax2012 и выпилили - майкрософт топил за Reporting Service

вернее, внешние генераторы отчетов должны ожидать такого поведения от системы. Собственно так работают многие закрытые системы.

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

[Lemming]

Цитата:

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

легко. наследование таблиц, которое вводили в ax2012, это на самом деле расширение таблиц.

ядро отвечает за join таблиц расширений.
каждый плагин получает tableBase join tablePluginN

Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?

[sukhanchik]

Цитата:

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

Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?

Решение, не требующее плагинов.
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 оставляет за собой право пересмотреть порядок в любой момент времени)

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

[mazzy]

Цитата:

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

Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?

Цитата:

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

Решение, не требующее плагинов.
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)

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

в старых аксаптах пример псевдоплагинных таблиц InventTableModule (с большими оговорками)

в ax2009 типичный пример псевдоплагинных таблиц - LedgerJournalTrans


в ax2012 таких псевдоплагинных таблиц уже много, поскольку пришло много разработчиков со Scala. Особенно "удались" расширения для стран (PL, BR и др.)
sukhanchik привел пример для SalesTable


мой же любимый пример из ax2012 - это конечно базовая таблица unitOfMeasure и таблица-расширение unitOfMeasure_W, которая содержит 2 (два!) поля. Одно из которых является ссылкой на запись в базовой таблице.

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

в общем, unitOfMeasure_W - типичный образчик того, как расширяют таблицы в мире закрытых систем с плагинами.

[sukhanchik]

Цитата:

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

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

Верно, реализация - полное г... Но в качестве идеи подходит. Можно обратиться и к предыдущим версиям и посмотреть, как сказал mazzy - на тамошнюю реализацию (LedgerJournalTrans)

[belugin]

Цитата:

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

в ax2012 таких псевдоплагинных таблиц уже много, поскольку пришло много разработчиков со Scala. Особенно "удались" расширения для стран (PL, BR и др.)
sukhanchik привел пример для SalesTable

В 2012 в рамках проекта OneGLS были объединены слои GLS для APAC, LATAM и EMEA в один. Чтобы можно было сделать Multinational у которого одна компания бразильская, другая - латвийская, например.

Если бы оставили все в одной таблице, то количество полей бы превысило пределы которые обрабатывает AOS по умолчанию, так же пустые денные забивали буферы на SQL Server (например в одной компании нужны только бразильские поля и там миллиард записей, в другой компании только польские и там тоже миллиард записей, а запросы обычно запрашивают данныетолько одной компании).

Конкретно про UnitOfWork сказать не могу

[mazzy]

Цитата:

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

В 2012 в рамках проекта OneGLS были объединены слои GLS для APAC, LATAM и EMEA в один. Чтобы можно было сделать Multinational у которого одна компания бразильская, другая - латвийская, например.

Если бы оставили все в одной таблице, то количество полей бы превысило пределы которые обрабатывает AOS по умолчанию, так же пустые денные забивали буферы на SQL Server (например в одной компании нужны только бразильские поля и там миллиард записей, в другой компании только польские и там тоже миллиард записей, а запросы обычно запрашивают данныетолько одной компании).

Конкретно про UnitOfWork сказать не могу

Да, я слышал эту легенду.

Если "количество полей бы превысило пределы которые обрабатывает AOS по умолчанию", то надо разбивать таблицу по количеству полей ПО связанности полей друг с другом (по смыслу). Т.е. надо было бы отрефакторить функционал.

А сделали разбитие "по странам", полностью игнорируя как поля используются, как взаимодействуют.
Типа в очередной раз Майкрософт решил свои технические проблемы за счет потребителей. Причем именно тех потребителей, которые и являются заинтересованным ядром ("у которого одна компания бразильская, другая - латвийская, например")

Поэтому легенда так себе, фиговенькая. Особенно, если она правда.