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

[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 по умолчанию", то надо разбивать таблицу по количеству полей ПО связанности полей друг с другом (по смыслу). Т.е. надо было бы отрефакторить функционал.

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

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

[belugin]

Цитата:

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

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

Это не легенда. Я обычно отделяю свои предположения от наблюдаемых фактов.

Цитата:

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

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

Не затруднит ли тебя оценить количество работы и вероятное число багов которые упали бы на плечи клиентов для анализа всех слоев GLS на предмет связанности этих полей? Можно еще сравнить с преобразовнием кода и тестов по границам, каоторые уже были проведены по GLS слоям.

[mazzy]

Цитата:

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

на плечи клиентов

на плечи клиентов?!

Тебя там связали и пытают что ли?
Поставь точку в конце следующего сообщения, если ты не можешь говорить свободно.
https://www.youtube.com/watch?v=llFmOMCJLgk

[AlexSD]

Цитата:

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

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

Мы там как-то суммировали количество кода российской + восточноевропеской локализации. Получилось что-то около 1 милиона строк. При том, что весь остальной "западный" функционал был тогда 3 миллиона строк. Не скажу, что это был только чистый код. Кажется, мы там просто суммировали количество строк в xpo. Но не в этом дело, а дело в соотношении между локализацией и основным кодом.
Вот этот миллион строк в 4-ке аптейкали 2 ПМа, 5 разработчиков и 3 тестера. Времени еле-еле хватало что бы только переложить код из 3-ки в 4-ку. При этом набо было добавлять и новый функционал для новых законов. 2009-ю делали большим количеством людей, но не сильно много.

"Каждый день к девяти утра я должен идти в мой магистрат. Я не скажу, что это подвиг, но вообще что-то героическое в этом есть ..." (С)