|
23.05.2021, 14:42 | #1 |
Участник
|
Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?
|
|
23.05.2021, 17:35 | #2 |
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 | #3 |
Участник
|
Цитата:
Цитата:
но в отсутствие плагинов сделали как смогли - неуправляемо захадкожено и совершенно спрятано-невидимо для внешних систем. в старых аксаптах пример псевдоплагинных таблиц 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 | #4 |
Administrator
|
Верно, реализация - полное г... Но в качестве идеи подходит. Можно обратиться и к предыдущим версиям и посмотреть, как сказал mazzy - на тамошнюю реализацию (LedgerJournalTrans)
__________________
Возможно сделать все. Вопрос времени |
|
24.05.2021, 09:42 | #5 |
Участник
|
Цитата:
Если бы оставили все в одной таблице, то количество полей бы превысило пределы которые обрабатывает AOS по умолчанию, так же пустые денные забивали буферы на SQL Server (например в одной компании нужны только бразильские поля и там миллиард записей, в другой компании только польские и там тоже миллиард записей, а запросы обычно запрашивают данныетолько одной компании). Конкретно про UnitOfWork сказать не могу |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
24.05.2021, 11:14 | #6 |
Участник
|
Цитата:
Сообщение от belugin
В 2012 в рамках проекта OneGLS были объединены слои GLS для APAC, LATAM и EMEA в один. Чтобы можно было сделать Multinational у которого одна компания бразильская, другая - латвийская, например.
Если бы оставили все в одной таблице, то количество полей бы превысило пределы которые обрабатывает AOS по умолчанию, так же пустые денные забивали буферы на SQL Server (например в одной компании нужны только бразильские поля и там миллиард записей, в другой компании только польские и там тоже миллиард записей, а запросы обычно запрашивают данныетолько одной компании). Конкретно про UnitOfWork сказать не могу Если "количество полей бы превысило пределы которые обрабатывает AOS по умолчанию", то надо разбивать таблицу по количеству полей ПО связанности полей друг с другом (по смыслу). Т.е. надо было бы отрефакторить функционал. А сделали разбитие "по странам", полностью игнорируя как поля используются, как взаимодействуют. Типа в очередной раз Майкрософт решил свои технические проблемы за счет потребителей. Причем именно тех потребителей, которые и являются заинтересованным ядром ("у которого одна компания бразильская, другая - латвийская, например") Поэтому легенда так себе, фиговенькая. Особенно, если она правда. |
|
24.05.2021, 12:09 | #7 |
Участник
|
Это не легенда. Я обычно отделяю свои предположения от наблюдаемых фактов.
Не затруднит ли тебя оценить количество работы и вероятное число багов которые упали бы на плечи клиентов для анализа всех слоев GLS на предмет связанности этих полей? Можно еще сравнить с преобразовнием кода и тестов по границам, каоторые уже были проведены по GLS слоям. |
|
24.05.2021, 14:35 | #8 |
Участник
|
на плечи клиентов?!
Тебя там связали и пытают что ли? Поставь точку в конце следующего сообщения, если ты не можешь говорить свободно. https://www.youtube.com/watch?v=llFmOMCJLgk Последний раз редактировалось mazzy; 24.05.2021 в 14:38. |
|
27.05.2021, 03:51 | #9 |
Microsoft Dynamics
|
Мы там как-то суммировали количество кода российской + восточноевропеской локализации. Получилось что-то около 1 милиона строк. При том, что весь остальной "западный" функционал был тогда 3 миллиона строк. Не скажу, что это был только чистый код. Кажется, мы там просто суммировали количество строк в xpo. Но не в этом дело, а дело в соотношении между локализацией и основным кодом.
Вот этот миллион строк в 4-ке аптейкали 2 ПМа, 5 разработчиков и 3 тестера. Времени еле-еле хватало что бы только переложить код из 3-ки в 4-ку. При этом набо было добавлять и новый функционал для новых законов. 2009-ю делали большим количеством людей, но не сильно много. "Каждый день к девяти утра я должен идти в мой магистрат. Я не скажу, что это подвиг, но вообще что-то героическое в этом есть ..." (С) Последний раз редактировалось AlexSD; 27.05.2021 в 03:55. |
|
|
За это сообщение автора поблагодарили: Lemming (5). |