join-ы

[belugin]

Невозможно выбрать запись в 'Таблица конфигурации' ('ConfigTable')
Использован оператор объединения таблиц join, но выражение WHERE не содержит связи между таблицами.

static void Test3Tables(Args _args)
{
    QueryRun qr =
        SYS_ExpressionQueryBuilder::addDataSource(tableNum(InventSum), 'InventSum')
            .join(tableNum(InventDim))
            .link(fieldNum(InventSum, InventDimID),
                  fieldNum(InventDim, InventDimID))
            .outerJoin(tableNum(ConfigTable), 'ConfigTable')
                .link(fieldNum(InventDim, ConfigId),
                      fieldNum(ConfigTable, ConfigId))
            .matches(fieldNum(ConfigTable, RecID), '(ConfigTable.ItemId==InventSum.ItemID)')
            .run();
    ;
    qr.next();
}

[EVGL]

Цитата:

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

Невозможно выбрать запись в 'Таблица конфигурации' ('ConfigTable')
Использован оператор объединения таблиц join, но выражение WHERE не содержит связи между таблицами.

static void Test3Tables(Args _args)
{
    QueryRun qr =
        SYS_ExpressionQueryBuilder::addDataSource(tableNum(InventSum), 'InventSum')
            .join(tableNum(InventDim))
            .link(fieldNum(InventSum, InventDimID),
                  fieldNum(InventDim, InventDimID))
            .outerJoin(tableNum(ConfigTable), 'ConfigTable')
                .link(fieldNum(InventDim, ConfigId),
                      fieldNum(ConfigTable, ConfigId))
            .matches(fieldNum(ConfigTable, RecID), '(ConfigTable.ItemId==InventSum.ItemID)')
            .run();
    ;
    qr.next();
}

Встретился с фирменным стилем belugin в классе CustVendPaymERExport. Кратко, изящно, все нужные методы private, невозможно вклиниться и расширить. Спасибо огромное, продолжайте в том же духе и мы останемся на 7.2.

[belugin]

Можно ли узнать, что именно необходимо расширить и какой код в 7.2?

См. также обсуждение некоторых изменений модуля в 7.3

[Logger]

Цитата:

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

Можно ли узнать, что именно необходимо расширить и какой код в 7.2?

Максим, а вот такое выражение

            .link(fieldNum(InventSum, InventDimID),
                  fieldNum(InventDim, InventDimID))

можно заменить чем то типа

            .linkRelation('\Data Dictionary\Tables\InventSum\Relations\InventDim')

?

Так бы лучше инкапсуляция была и можно было бы проверку от опечаток сделать внутри вызова linkRelation(). Тогда не было бы ситуации когда в имени таблицы или поля опечатался и запрос работает, но неправильно.

[belugin]

Цитата:

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

            .linkRelation('\Data Dictionary\Tables\InventSum\Relations\InventDim')

Так бы лучше инкапсуляция была и можно было бы проверку от опечаток сделать внутри вызова linkRelation(). Тогда не было бы ситуации когда в имени таблицы или поля опечатался и запрос работает, но неправильно.

Теоретически я бы делал так:

.linkRelation(tableStr(InventSum), relationStr(InventSum, InventDim))

Но у нас нет relationStr так, что если кто-то переименует relation, мы узнаем только в runtime. Если вы пишете тесты, то это небольшое неудобство, но если нет, вам могут сломать код, а узнает об этом только пользователь.

[Logger]

Цитата:

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

Но у нас нет relationStr так, что если кто-то переименует relation, мы узнаем только в runtime.

Это намного лучше, чем если отработает, но не с теми полями. Уж лучше пусть ошибка в рантайм.

[trud]

Цитата:

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

Встретился с фирменным стилем belugin в классе CustVendPaymERExport.

Кстати да, не в обиду, но хорошее замечание. т.е. нарушается одно из правил кодеревью что код не должен быть персонализирован(а так в АХ больше никто не пишет)
читать такой код на мой взгляд сложно(непонятно на каком классе вызывается методы), да и отлаживать подозреваю тоже
как вообще такое пропускают

[belugin]

За несколько лет никто не жаловался именно на это. Это не фирменный стиль belugin это FluentInterface - распространенный прием в языках, где нет property и collection initializers (например в java, с которой слизали X++).

Их не надо отлаживать особо - там никакой логики нет, только передача параметров.

BTW у отладчика в VS гораздо больше возможностей, чем то, к чему мы привыкли на предыдущих версиях AX (step into specific, tracepoints, conditional breakpoints, etc) если вдруг кто-то не знает что-то из этого, рекомендую почитать доку.

[ax_mct]

Цитата:

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

За несколько лет никто не жаловался именно на это. Это не фирменный стиль belugin это FluentInterface - распространенный прием в языках, где нет property и collection initializers (например в java, с которой слизали X++).

Их не надо отлаживать особо - там никакой логики нет, только передача параметров.

BTW у отладчика в VS гораздо больше возможностей, чем то, к чему мы привыкли на предыдущих версиях AX (step into specific, tracepoints, conditional breakpoints, etc) если вдруг кто-то не знает что-то из этого, рекомендую почитать доку.

Бить по рукам надо линейкой за FluentInterface

c1.FirstName("vinod").LastName("srivastav").Sex("male").Address("bangalore").Print();

И категорически запрещать. Каждый раз проклинаю. И ни разу не порадовался.

А по теме, раз отчет то делайте временную таблицу и забудьте о нюансах join, делайте максимально тупо.
Вот на форме, да стоит думать, но для отчета нет смысла. Для отчета нужна гибкость, а это временная таблица.

[belugin]

Цитата:

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

Бить по рукам надо линейкой за FluentInterface

c1.FirstName("vinod").LastName("srivastav").Sex("male").Address("bangalore").Print();

Почему в одну строчку и не со значимым именем? Слишком читаемо?

Цитата:

И категорически запрещать. Каждый раз проклинаю. И ни разу не порадовался.

Можно включить левое полушарие и вместо эмоций привести аргументы?

Цитата:

А по теме, раз отчет то делайте временную таблицу и забудьте о нюансах join, делайте максимально тупо.

А как данные будут приходить во временную таблицу? За каждой связанной записью ходить на SQL Server? Или тот же join?

[ax_mct]

Цитата:

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

Почему в одну строчку и не со значимым именем? Слишком читаемо?
Можно включить левое полушарие и вместо эмоций привести аргументы?

А как данные будут приходить во временную таблицу? За каждой связанной записью ходить на SQL Server? Или тот же join?

Ни один "системный" программист не может вообразить всех потребностей "прикладного".
Сам каждый раз поражаюсь требованиям и ситуациям.

Возможность дебажить и расширять. Вот что нужно "прикладному" программисту.
Экономия на переменных и строках, для красоты - это говнокод на самом деле. То есть красиво придавленное но г@вно.

Даже инициализацию параметров требуется дебажить и иногда менять. А когда иерархия и все в строку да с запуском в конце то уматываешься проходить по всем параметрам пока до нужного метода доберешься. Часто приходиться переписывать такой код добавляя переменные для удобства дебага.

Те же join это примерно такая же "оптимизация" как и сокращенный код. В топку такую оптимизацию.
Лучше лишний раз сходить на SQL Server. Не нужно ничего оптимизировать заранее и без реальной на то необходимости.

[Link]

Цитата:

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

Можно включить левое полушарие и вместо эмоций привести аргументы?

Коллега конечно излишне эмоционален, но я тоже считаю, что такого кода не должно быть в стандарте. Ну и сам X++ Coding Standards:

General Guidelines

• Only one statement per line.
  
• Break up complex expressions that are more than one line - make it visually clear.
  
• Use a single blank line to separate entities.