D365FO: Navigation methods are not supported at this time?

[mazzy]

Цитата:

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

Почему не поддерживается. Поддерживается, то только без экстеншенов.

ээээ. а что делать с экстеншенами?
и как их использовать в UnitOfWork?

Цитата:

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

А кстати какая идея вообще стоит за UnitOfWork, почему нельзя просто присваивать связи в транзакции?

Ты меня об этом спрашиваешь?
Почему бы не спросить авторов этого чуда.

Насколько я понимаю:
1. ноги растут из традиционного программирования, где для каждой таблички создается dto-класс. и традиционных ORM.
2. задача - минимизировать операции с базой данных за счет того, что в базу передается не каждое изменение в dto-классе, а некие "значимые состояния"
3. в аксапте типичный где UnitOfWork очень пригодился бы - это InventSumDelta - суммирование происходит "в памяти" транзакция записывает в InventSum только "финальный" итог.

В аксапте какой-то деятель начал использовать UnitOfWork совсем для других целей. "Поясню".

В аксапте некие другие деятели в 2012 решили перейти на искусственные индексы по RecId. Для этого было добавлена куча пропертей в объектах, добавлены новые понятия типа Replacement Index, введены новые типы контролов, которые автоматически делают разыменование искусственных индексов (но при этом теряют поиск по этому полю )

В принципе, решали проблему "медленной генерации ключевых полей". С прицелом передать генерацию RecId на SQL server. И даже попытаться воспользоваться родным SQL-ным autoIncrement-ом.

В общем, решили и сделали.

И! вдруг! обнаружили! что искусственные ключи ведут себя совершенно иначе в массовых операциях.

как происходят массовые операции для связанных таблиц для "наших" ключей:
1. мы генерим код (обычно вызываем NumSeq)
2. заполняем мастер-справочник данными
3. -
4. заполняем подчиненные справочники данными
5. заполняем в подчиненных справочниках сгенеренный код (который мы знаем)
6. используем какой-нибудь insertRecorset, SortedList для массового обновления данных

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

как происходят массовые операции для связанных таблиц для "системных" ключей.
1. -
2. заполняем мастер-справочник данными
3. записываем в БД(!), получаем сгенеренный системой recID
4. заполняем подчиненные справочники данными
5. заполняем в подчиненных справочниках recID
6. записываем данные из подчиненного справочника (уже неважно как)

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

ситуация сильно ухудшается, если мы имеем дело с итерационными процессами типа обновления себестоимости (см. InventSumDelta)

===========
естественно, доблестные программисты начали решать "проблему", которую создали архитекторы, абсолютно программистскими методами.

См. класс systemSequence и обслуживающий его ужас в виде "appl.sysRecIdSequence()"

Ax2009, сбросить кеш recid SystemSequences

http://sinedax.blogspot.com/2018/09/...-dynamics.html

но это "проблема" чисто программистскими методами не решается, поскольку сидит на архитектурном уровне . Поэтому на программистском уровне пришлось вводить методы suspendRecIds/removeRecIdSuspension

до сих пор непонятно приостанавливают ли эти методы выделение recID глобально (для всех потоков) или только для одного потока. Есть разные мнения. но если приостанавливают глобально, то это полный пипец для производительности.

на архитектурном уровне suspendRecIds для таблицы тут же запрещает рекурсивные алгоритмы и алгоритмы, которые "внутре" могут вызвать создание записей в этой же таблице. (Прощай деревья!)

"Сходили за хлебушком" называется, ускорили индексы заменив "длинные" и составные строковые ключи на "короткие" recID - запретили массовые операциии с БД, ввели stop-world-паттерн, поломали деревья.

но даже если suspendRecIds приостанавливает выделение только в области видимости переменной systemSequence, как CodePermission (будь проклят тот архитектор, который принял решение добавить эту хрень в аксапту), то все равно остается непонятным как на самом деле ЭТО ведет себя если будет выброшено исключение (suspendRecIds сработал, а до removeRecIdSuspension не дошли) и что будет с UserConnection...

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

и тут возник Unit Of Work.
который в основе своей использует эти самые навигационные методы...

но внезапно(!), видимо, другая команда добавила наследование таблиц в 2012
в результате борьбы бульдогов под ковром (там еще и отдел отчетности встрял) в ax2012sp1 наследование было выброшено на помойку...
ну.. как...
на уровне SQL никакого наследования нет - все в одной таблице.
но зато на уровне AOT совершенно дикое и никем не принятое наследование.

Хорошо, сделали Unit Of Work перестал ругаться на наследование.
но похоже пришла беда откуда не ждали - extensions в D365