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