join-ы

[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. Не нужно ничего оптимизировать заранее и без реальной на то необходимости.

[belugin]

Цитата:

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

Возможность дебажить и расширять.

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

У нас не очень много такого кода в production но много такого в тестах.

Учтите, что в AX7 можно просто провалиться по F12 в метод и поставить breakpoint уже там.

К сожалению, в X++ (в отличие от C#) не работает "step into specific" и бряки по имени функции.

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

Про возможность расширять, я не очень понял. EVGL сказал, нашел две проблемы:
1. private методы
2. создание запроса не выделено в отдельный метод

По-моему, это ортогонально стилю заполнения параметров.

Цитата:

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

Никакой красоты нет. Есть время на чтение и удобство анализа кода. Если есть дублирование, то для анализа надо сканить дубли на предмет различий. Я много раз ловил ошибки типа "скопировали, но забли поменять имя переменной".

Цитата:

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

В каком смысле "иерархия и все строку" обычно разбивается по нескольким строкам?

Цитата:

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

Как я уже говорил, можно поставить бряку внутрь метода. Учтите, что VS позволяет смотреть возвращаемое в методе значение.

Цитата:

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

А если 200000 раз?

[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.

[belugin]

Цитата:

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

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

Моя претензия не к тому что есть эмоции, а к тому, что в исходном сообщении не было ничего кроме них. А так, лично для меня, пусть хоть матом ругается только по делу.

Цитата:

Only one statement per line.

Не очень совместимо с длинными именами (если читать как one and only one - я прочитал как "на каждую строчку должен приходиться только один statement (но он может быть и несколько строчек)") - нельзя разбивать вызов на несколько строчек.

Цитата:

Break up complex expressions that are more than one line - make it visually clear.

Если речь идет про выделение переменных, мне кажется, вложенность описанная отступами более визуальна, чем несколькими присваиваниями на одном уровне.

Цитата:

Use a single blank line to separate entities.

Непонятно, при чем тут это.