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

[Maxim Gorbunov]

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

))))

[Maxim Gorbunov]

Цитата:

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

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

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

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

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

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

[S.Kuskov]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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