Косячок в классе 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 для этого вроде, к счастью, нигде больше не используется.