Косячок в классе InventAdj_Cancel (fetchMode)

[gl00mie]

Наткнулся сегодня на «интересный» способ указывать fetchMode в Query. Так, в методе InventAdj_Cancel.updateMultipleInvent() есть такие интересные строчки (AX 3.0 SP5 FP1)

inventSettlementDataSource = inventClosingDataSource.addDataSource(
                                        tableNum(InventSettlement));
inventSettlementDataSource.fetchMode(JoinMode::INNERJOIN);

Ну, казалось бы, ерунда, JoinMode::InnerJoin = 1 == QueryFetchMode::One2One, но далее в том же методе код еще интереснее

inventTransDataSource = inventSettlementDataSource.addDataSource(
                                        TableNum(InventTrans));
inventTransDataSource.fetchMode(JoinMode::ExistsJoin);

Я подозреваю, что Axapta при обработке свойства fetchMode делает проверку типа

if(fetchMode) { /* выборка 1:1 */ }

т.е. ей, возможно, плевать, что значению 2 никакой QueryFetchMode не соответствует, однако, использование «левых» констант в стандартном коде как-то смущает Решил на всякий случай проверить Inventory Closing Rollup 2 для AX 3.0 и код в AX 4.0 SP1. В первом случае указанный метод класса InventAdj_Cancel модификации не подвергся, а вот в 4-ке совсем интересно: вместо JoinMode::INNERJOIN там красуется JoinMode::InnerJoin, т.е., видимо, код «подчищали» (хотя бы в плане регистра идентификаторов и ключевых слов - всякие «TableNum» канули в Лету), но значения констант оставили прежними: там все так же красуется fetchMode(JoinMode::ExistsJoin)
Использование JoinMode::InnerJoin в AX 3.0 SP5 FP1 для установки fetchMode встречается еще в методах RAssetCreateTaxAccount.new() и Tax.queryTaxCodeIntersection(), JoinMode::ExistsJoin для этого вроде, к счастью, нигде больше не используется.

[EVGL]

Да. Смешно читать, как M. F. Pontoppidan надувает щеки и с гордостью пишет, что в версии 4.0 устранены все отклонения от Best Practices. Во-первых, не устранены, а во-вторых, все это сделали чисто механически, и с прикладной точки зрения код едва ли улучшился.

Мне это отдаленно напоминает одного программиста-дуболома из бывшего австрийского Коламбуса. При переходе на 3.0, как вы помните, проверка на ttsbegin перед .update() была ужесточена. Так этот кретин выгрузил весь код из VAR-слоя в XPO (!) и в текстовом редакторе обрамил все вызовы:

ttsbegin;
xxx.update();
ttscommit;

Нетрудно догадаться, что приложение перестало работать совсем.

[glibs]

Цитата:

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

...
в версии 4.0 устранены все отклонения от Best Practices.
...

Где???!!!

Скомпилируйте какой-нибудь класс Global...

Только это... Нажмите сначала Сервис\Параметры, кнопочка Компилятор, в поле Уровень диагностики Уровень 4. Только это не все. Потом Кнопочка Рекомендации и в самом верху в поле Уровень предупреждения выберите Все, а не Ошибки.

983 отклонений от ВР.

Или мой "любимый" класс WebFormHtml

1100 отклонений от ВР.

Причем если в Global в восточноевропейской версии может быть код локализаторов (лень смотреть, но раньше был), то в WebFormHtml они точно не лазили.

Так чего они там такого "сделали" с отклонениями? По умолчанию проверку по ВР попросили сообщать только об ошибках?