Выбор записей из таблицы произвольным запросом

[Maxim Gorbunov]

Цитата:

Сообщение от S.Kuskov

Это если логика отбора покрывается возможностями Query

Вопрос исключительно для моего общего развития: а чего такого не умеет Query?

Ну и для полноты картины замечу, что если уж вам хочется ещё больше гибкости, то можно сделать наследника класса SysSearchBase, всю логику отбора записей упаковать в него, и возвращать его вместо Query. Код, использующий этот класс, будет только дёргать метод next(). Хотите примеров - смотрите класс BOMSearch и то, как он используется в BOMCopyFromBOM.copy().

[S.Kuskov]

Цитата:

Сообщение от Maxim Gorbunov

Вопрос исключительно для моего общего развития: а чего такого не умеет Query?

Много чего..., case when, например.

[Maxim Gorbunov]

Цитата:

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

да, но тут снова встает ограничение аксапты - на одно поле - одна агрегатная функция.
в результате получить отдельно дебетовые и кредитовые обороты в одном запросе по одной таблице становится проблематично.

По-моему, мы всё дальше уходим от исходной задачи, но я отвечу

Как и многие другие проблемы, эта решается с помощью создания промежуточных View. Во view можно сделать сколько угодно полей, которые будут разными агрегатными функциями на основе одного поля физической таблиц (см. View CustPackingSlipMinMaxDates; к сожалению, только в AX2012, но в AX2009 это тоже работает).

Правда, собрать дебет отдельно от кредита это не поможет. Тут как раз агрегатная функция одна, но фильтры разные. Но и эту задачу можно решить путём создания промежуточных View. В AX2012 во view можно добавлять computed columns, так что можно сделать View на основе базовой таблицы и добавить в него поля AmountDebit и AmountCredit, а потом суммировать их сколько угодно. В AX2009 computed columns нет, но задача, в принципе, тоже решаема, только придётся повозиться, чтобы правильно сделать cross join между двумя датасорсами, в одном из которых будут собраны дебетовые проводки, а в другом - кредитовые.

[Maxim Gorbunov]

Цитата:

Сообщение от S.Kuskov

Много чего..., case when, например.

Понятно. Я думал, while select что-то такое умеет, чего не умеет Query, но while select тоже не умеет case when.

В AX2012 эта проблема решена с помощью computed columns, которые можно добавлять к View (например, см. View VendTableCube). В AX2009 с этим сложнее, но часто можно обойти с помощью обычных display-методов на таблицах.

[mazzy]

Цитата:

Сообщение от Maxim Gorbunov

Как и многие другие проблемы, эта решается с помощью создания промежуточных View.

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

Цитата:

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

раз все равно придется делать классы, отвечающие за бизнес-сущности,
то может и не заморачиваться с "произвольным запросом"
а сразу сделать нормальные классы? ))))

))))

[mazzy]

Цитата:

Сообщение от Maxim Gorbunov

В AX2009 с этим сложнее, но часто можно обойти с помощью обычных display-методов на таблицах.

ты ведь точно не забываешь о группировках?
ты ведь точно говоришь не только о переборе на уровне записей?

[Maxim Gorbunov]

Цитата:

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

ты ведь точно не забываешь о группировках?
ты ведь точно говоришь не только о переборе на уровне записей?

Точно не забываю
На View тоже можно создавать display-методы

[sukhanchik]

Цитата:

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

закольцованные через inventSettlement? тогда нужно больше одной таблицы )))
или ты лот возврата имеешь в виду. а как у него кольцо может образоваться?

InventSettlement тут ни при чем. Да, тут будет 2 таблицы - если еще считать InventDim. Но RecId из InventDim обычно никому неинтересны, в отличие от RecId из InventTrans.
Речь идет о переносе товара между складами, когда товар со склада А переносится
на склад Б, с Б на В, с В на Г и т.д. А потом где-то с Ж снова на А или на Б. А теперь представим себе, что у нас помимо склада еще есть что-нибудь типа номера ГТД и/или партии и ... далее по списку аналитик.

В 4.0 была масса косяков в проставлении складских аналитик у заказов на перемещений. В результате могло получиться так, что товар списывался по одним аналитикам, а зачислялся по другим. Само собой АХ дальше-то работала верно, но закрытие склада вешалось из-за того, что переносы, перемещения, спецификации, закупки и продажи сопоставлялись ээээ ну в общем не так, как это ожидалось пользователями.

[Maxim Gorbunov]

Цитата:

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

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

Я не очень понимаю, к чему ты ведёшь. Вероятно, это всё-таки не мне был ответ. Если ты хочешь поговорить о data entities, можно, конечно, и об этом порассуждать, только какое отношение это имеет к выбору записей из базы? Делаешь ты поверх всего этого entity или нет - логику выбора записей тебе внутри всё равно реализовывать придётся.

Комбинироваться эти view могут с помощью других view, и таких примеров уже очень много в стандартном приложении. Посмотри, например, на View InventValueTransView, который собирается (через View InventValueTransUnionAll) из нескольких других View, которые в основе своей имеют InventTrans и InventSettlement, отфильтрованные по разным наборам критериев.

Скажу так: за бизнес-сущность вовсе не обязан отвечать класс. Это может быть и View, и Query. Ну или правильнее будет сказать, что класс, отвечающий за бизнес-сущность - это совсем не обязательно класс в смысле объекта AOT типа "класс".

P.S.: Я, наверное, дальше в этой ветке буду только на прикладные вопросы отвечать. Абстрактные идеологические рассуждения, конечно, тоже иногда интересны, но, пожалуй, не сегодня

[Maxim Gorbunov]

Чтобы окончательно добить тему, поделюсь небольшой идей.

Как я уже писал, в AX2009 нет computed columns, но это, разумеется, не преграда пытливому уму и неугомонным рукам

В качестве дисклеймера:

1. Если вам кажется, что ваша задача требует применения этого решения, остановитесь и подумайте. Возможно, задачу можно переформулировать так, что computed columns будут не нужны.
2. Если вы всё ещё считаете, что вам необходимы computed columns в AX2009, подумайте ещё раз.
3. Если ваша настойчивость не знает границ, то так и быть, делайте, но учтите, что нижеприведённый код - это proof-of-concept, и его надо дорабатывать перед переносом в рабочую среду.

Итак, задача: сделать в AX2009 view на основе таблицы LedgerTrans, в котором дебетовые и кредитовые суммы будут в разных полях, чтобы потом можно было группировками собирать дебетовые и кредитовые обороты.

1. Создаём View, как показано на рисунке. Поля AmountMST, AmountMSTDebit и AmountMSTCredit привязаны к одному и тому же полю LedgerTrans.AmountMST. Статический метод synchronize() пока сделаем пустым.
   
2. Ищем в AOT класс Application и его метод dbSynchronize(). В конец этого метода добавляем следующую строчку:
   

   LedgerTransDebCredView::synchronize();

3. Возвращаемся в метод synchornize() на нашем view и пишем в него следующий код:
   

   public static void synchronize()
   {
       UserConnection  userConnection;
       str             sqlStatement;
       Statement       statement;
       ;
   
       sqlStatement =
           'ALTER VIEW [dbo].[LEDGERTRANSDEBCREDVIEW] AS ' +
           'SELECT ' +
           '   A.ACCOUNTNUM AS ACCOUNTNUM, ' +
           '   A.TRANSDATE AS TRANSDATE, ' +
           '   A.VOUCHER AS VOUCHER, ' +
           '   A.TXT AS TXT, ' +
           '   A.AMOUNTMST AS AMOUNTMST, ' +
           '   CASE WHEN A.AMOUNTMST >= 0 THEN A.AMOUNTMST ELSE NULL END AS AMOUNTMSTDEBIT, ' +
           '   CASE WHEN A.AMOUNTMST <= 0 THEN A.AMOUNTMST ELSE NULL END AS AMOUNTMSTCREDIT, ' +
           '   A.DATAAREAID AS DATAAREAID, ' +
           '   A.RECID AS RECID ' +
           'FROM LEDGERTRANS A';
       new SqlStatementExecutePermission(sqlStatement).assert();
   
       userConnection = new UserConnection();
       statement = userConnection.createStatement();
       statement.executeUpdate(sqlStatement);
   
       CodeAccessPermission::revertAssert();
   }

4. Синхронизируем view LedgerTransDebCredView и открываем его Table browser'ом.
   

Ура, в поле AmountMSTDebit остались только дебетовые балансы, а в поле AmountMSTCredit - кредитовые.

[mazzy]

хитрый! прикольно

только:
не стоит возвращать null в числовое поле. лучше 0.

чтобы можно было оставить в качестве готового примера, стоит добавить обработку поля correction. это признак сторно. он есть и в международном функционале.

а в dbSynchronize точно попадает только пользователь с правами на изменение схемы? там точно никакой подмены на аосовского пользователя не происходит?
может в дисклаймер стоит добавить, что пользователю нужны права на alter view?

[EVGL]

Цитата:

Сообщение от S.Kuskov

Много чего..., case when, например.

Мне всегда DISTINCT во всей AX страшно не хватало: "найди самое последнее по времени Y с типом X, и выведи один раз для каждого X".
Решал, кстати, двумя view, в одном из которых был GROUP BY(X) и MAX(Y) того, что хотелось иметь первым, а второй view был построен на query inner join с первым view.

[S.Kuskov]

Цитата:

Сообщение от Maxim Gorbunov

Понятно. Я думал, while select что-то такое умеет, чего не умеет Query, но while select тоже не умеет case when.

Хотите таких примеров? Их есть у меня Сортировка Query
практический пример Добавление даты из партии в форму в наличие

[S.Kuskov]

Цитата:

Сообщение от Maxim Gorbunov

Комбинироваться эти view могут с помощью других view, и таких примеров уже очень много в стандартном приложении. Посмотри, например, на View InventValueTransView, который собирается (через View InventValueTransUnionAll) из нескольких других View, которые в основе своей имеют InventTrans и InventSettlement, отфильтрованные по разным наборам критериев

Не спорю View очень мощный инструмент. Особенно в варианте с подменой его текста на уровне SQL. Основное ограничение этого подхода не в вариативности комбинаций а в их гибкости. Что я имею в виду. Структура View фиксируется на уровне компиляции. Была бы возможность собрать нужную структуру View в runtime (по аналогии с query), цены бы ему не было.

[sukhanchik]

Цитата:

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

а в dbSynchronize точно попадает только пользователь с правами на изменение схемы? там точно никакой подмены на аосовского пользователя не происходит?
может в дисклаймер стоит добавить, что пользователю нужны права на alter view?

Application живет на сервере. Поэтому код исполняется пользователем, от имени которого запущен АОС. А уж этот-то пользователь обладает всеми правами на БД, ибо иначе никогда бы не проходила синхронизация. Метод Максима на вьюхе запускается там, откуда был вызван, т.е. с сервера. Т.о. дополнительных прав никому не нужно.

[Logger]

Цитата:

Сообщение от S.Kuskov

Хотите таких примеров? Их есть у меня Сортировка Query
практический пример Добавление даты из партии в форму в наличие

Еще в копилку
noFetch в Query(Run)