Ограничение выборки перед открытием формы - как лучше сделать?

[IKA]

Есть форма на основе временной таблицы, она показывает вычисленные значения для каждой номенклатуры(около 15 полей на каждую номенклатуру).
Нужно ограничить количество записей в нее попадающих.
Открывать сразу все, а потом накладывать фильтры - не вариант, тк она 100 лет рассчитываться будет + да и пользователю не нужны все записи. Они бы предпочли сразу указывать критерии,т.е какие номенклатуры им нужно рассчитать и показать.

Как по бест-практис правильней сделать?
Я пока думаю так:
1) класс MyClass- наследник runBase, кот показывает диалог для выбора критериев накладываемых на InventTable. Сформированный запрос по InventTable будет использоваться для ограничения количества номенклатур , попадающих в расчет врем талицы.
2) в его MyClass.run() по

new MenuFunction(menuitemdisplaystr(MyForm),MenuItemType::Display);

открыть мою форму MyForm (кот основана на врем таблице)
3) в init() MyForm через MyClass.parmQuery() достать и передать его в метод MyTmpTable:opulate(), который вставляет (на сервере) записи во врем таблицу и передает курсор обратно в форму.

Все, вроде, хорошо и должно, думаю, работать, но:

1) Может, лучше просто открывать сразу MyForm, но пустой и сделать кнопку на ней для задания критериев inventTable. По OK в диалоге критериев заполнять врем таблицу и заполнять форму данными. Все-таки для аксапты не оч типично запрашивать критерии запроса перед открытием формы.

2) Не лучше ли в классе runBase сразу же заполнять на основе inventTable буфер врем талицы и уже по сути заполненную таблицу передавать в форму MyForm . (а не передавать запрос inventTable в форму , а потом уже в метод MyTmpTable:opulate, как указано выше). Т.о, если класс на сервере выполняется и врем таблица на сервере создается, то мы избегаем передачи запроса по inventTable на клиент в форму MyForm

3)Еще варианты/предложения/альтернативы?

Спасибо

AX2009 RU2

[kashperuk]

Посмотрите, как сделано при открытии формы InventOnHand (list page), которая остатки по номенклатуре показывает.
Перед открытием там (в последних версиях системы) показывается диалог запроса, в котором отфильтровываются записи, после подтверждения открывается сама форма с уже отфильтрованными строками

[IKA]

Прошу прощения, не указала версию: AX2009 RU2
Не вижу формы параметров, когда открываю InventOnHand.
Можете вкратце описать реализацию?

[SRF]

Вариант 1 предпочтительнее, как мне кажется, поскольку он как минимум удобнее для пользователей, ведь что делать пользователю, если он вдруг решил другие номенклатуры посмотреть? Закрывать форму и открывать заново. А если будет кнопка, то можно перевыбрать только нажав на нее и указав другие фильтры, такие реализации есть в системе - например форма в закрытии и коррекции - УЗ\Периодические операции\Закрытие и коррекция\Корректировка, там кнопки в Наличии или Проводки(кнопка выбрать). В стандарте есть и другие места сделанные аналогично.

Вариант 2 тоже имеет право на жизнь, по крайней мере лучше уж сразу заполнять в классе, а не тащить сам квери в форму и там с ним как то возиться.

И еще такой момент, как правило формы с пред фильтром реализованы в узле запросов, например ГК\Запросы\Коды Операций, Банк\Запросы\Банковские проводки, но там постоянные таблицы.

ПС. Форма, о которой писал Иван, использует те же механизмы, что и форма ГК\Запросы\Коды Операций, в форме отображаются данные из постоянных таблиц.

[sukhanchik]

Цитата:

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

Есть форма на основе временной таблицы, она показывает вычисленные значения для каждой номенклатуры(около 15 полей на каждую номенклатуру).
Нужно ограничить количество записей в нее попадающих.
...
3)Еще варианты/предложения/альтернативы?
AX2009 RU2

Цитата:

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

Форма, о которой писал Иван, использует те же механизмы, что и форма ГК\Запросы\Коды Операций, в форме отображаются данные из постоянных таблиц.

Эх.... Порочная практика применения временных таблиц в том качестве, в котором они не предназначены для применения. По крайней мере в АХ 2009.
Если Вам надо решить задачу с временными таблицами - то вы ее не решите разумным способом за разумное время и так чтобы работало быстро. Будете изобретать велосипед и за ядро пытаться решать сколько записей выводить - так, чтобы было быстро для пользователя.

Сделайте постоянную таблицу и периодическую операцию, которая будет ее рассчитывать. Периодическую операцию можно будет запускать в пакете на сервере - она будет очень шустро отрабатывать. Ну а форма, основанная на постоянной таблице - будет открываться быстро на любом объеме данных - это уже стандартное поведение ядра системы.
Примеры в системе такого подхода тоже есть - закрытие склада, расчет сводного плана и т.д.

[IKA]

Цитата:

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

Эх.... Порочная практика применения временных таблиц в том качестве, в котором они не предназначены для применения. По крайней мере в АХ 2009..

Я,конечно,почнимаю о чем вы , но если честно, то они именно для этого и предназначены, а подход - все пересчитывать и хранить - это идеологически всегда "средство по бедности" - тк сервер не тянет бытрые расчеты , то придумываются всякие извращенные workarounds.
В случае кубов это оправдано , по идее такие данные как можно было бы вообще с пом view вытянуть
Но, к сожалению, вы правы часто в аксапте используется именно такой подход(

[IKA]

Цитата:

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

А если будет кнопка, то можно перевыбрать только нажав на нее и указав другие фильтры, такие реализации есть в системе - например форма в закрытии и коррекции - УЗ\Периодические операции\Закрытие и коррекция\Корректировка, там кнопки в Наличии или Проводки(кнопка выбрать). В стандарте есть и другие места сделанные аналогично.

Спасибо за пример. Как раз то, что надо!
Хотя сакральный смысл транзакции в InventAdjTransactSelect -> run () мне не ясен (вроде, для врем таблиц ttsbegin - как мертвому припарка, как и проверки на дедлоки). Я так понимаю, просто вслепую шаблоном для runBase->run воспользовались...

+ не совсем не понимаю, почему нельзя было вызвать по menuItemButton этот класс на форме InventAdjTransaction->ButtonGroup->Choose , зачем под кнопкой в clicked пишут prompt() и run() (да и executeQuery на DS можно было бы в классе выполнять)?

[SRF]

Цитата:

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

Спасибо за пример. Как раз то, что надо!
Хотя сакральный смысл транзакции в InventAdjTransactSelect -> run () мне не ясен (вроде, для врем таблиц ttsbegin - как мертвому припарка, как и проверки на дедлоки). Я так понимаю, просто вслепую шаблоном для runBase->run воспользовались...

+ не совсем не понимаю, почему нельзя было вызвать по menuItemButton этот класс на форме InventAdjTransaction->ButtonGroup->Choose , зачем под кнопкой в clicked пишут prompt() и run() (да и executeQuery на DS можно было бы в классе выполнять)?

Можно, но так реализовали, ведь если у вас будет пункт меню клиентский, а сам класс серверный, то разницы(с т.з. механизмы работы), где писать код по вызову prompt, run, executeQuery - в методе на форме или в методе main собственно нет.

А вот если у вас пункт меню будет серверный, то разница уже будет, как минимум в том, что метод executeQuery придется дергать серверу(доп. взаимодействие клиента и сервера), возможно, что-то придется поменять в передаче временной таблицы.

Цитата:

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

Если Вам надо решить задачу с временными таблицами - то вы ее не решите разумным способом за разумное время и так чтобы работало быстро.

Почему? Все зависит от критериев(способ, время) и ожидаемого результата(скорость).

Вот вариант начальной реализации - открывалась форма и по всем номенклатурам начинался расчет, действительно не лучший вариант использования временной таблицы, но меняем реализацию на открытие пустой формы, добавления кнопки расчета - реализация не займет много времени, способ не разумный? или медленно работать будет ? Полный расчет для временной и постоянной таблицы на всем объеме данных будет сравним(как я понимаю, потому что основное время отъедает именно расчет полей), единственным по сути отличием будет то, что задание для постоянной таблицы можно поставить в пакет, НО это еще при условии, что в форме не нужно отображение актуальных данных, а-ля цена, остатки, еще что нибудь, в противном случае мы и в пакет то задание поставить не сможем.

Цитата:

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

Будете изобретать велосипед и за ядро пытаться решать сколько записей выводить - так, чтобы было быстро для пользователя.

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

Цитата:

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

Ну а форма, основанная на постоянной таблице - будет открываться быстро на любом объеме данных - это уже стандартное поведение ядра системы.

Небольшая поправка, не всегда, все зависит от группировок и сортировок используемых в форме.

Цитата:

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

Он будет как минимум за счет скорости открытия формы. Да и если использовать класс RecordInsertList для вставки записей - то даже на этапе перелива уже будет выигрыш

Да эффект будет, но если основное время при открытии формы занимает расчет полей, что как я понимаю в данной задаче и является основной проблемой - то почему бы быстро не уменьшить объем рассчитываемых данных ?

Я это к тому (грубые прикидки): что вот форма предположим сейчас открывается 3 часа для 1000 позиций, переделываем на постоянную - получаем скажем 30 минут расчета в пакете, теперь форма для всех позиций открывается 0,5 секунд(но это в случае, если скажем нет необходимости в оперативных данных).

Если мы просто фильтруем рассчитываемые позиции по 10-20, то получаем, что на каждую выборку мы тратим 100-200 секунд, что естественно гораздо больше 0,5, но в тоже время существенно меньше 3 часов.

[kashperuk]

Цитата:

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

Прошу прощения, не указала версию: AX2009 RU2
Не вижу формы параметров, когда открываю InventOnHand.
Можете вкратце описать реализацию?

Я бегло глянул, вроде там ничего не придумывали заумного, прям на самой форме сделали, перед выполнением запроса, следующий код:

    //when opening from back/forward (history) do not display query form
    if (this.args().dataset() != tableNum(InventSum))
    {
        queryRunCriteria = new SysQueryRun(inventSum_ds.query());
        queryRunCriteria.promptAllowAddDataSource(false);

        //we display form to modify query criteria in order to mitigate problems with bad performance when large amount of data
        //a user can set up filtering that will be used when the form is opened - this way the user can limit amount of data to be processed
        //the performance problem is due to the query being 'heavy' because of aggregation
        if (queryRunCriteria.prompt())
        {
            inventSum_ds.query(queryRunCriteria.query());
        }
    }
    inventSum_ds.executeQuery();

[IKA]

Цитата:

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

Я бегло глянул, вроде там ничего не придумывали заумного, прям на самой форме сделали, перед выполнением запроса, следующий код:
[/xpp]

спасибо.

[raz]

Ну вместо временной таблицы можно и нормальную таблицу использовать, просто разделять данные разных пользователей по какому то полю. При запуске формы заполнять, при закрытии очищать. Будет и скорость обычной таблицы, и не нужно периодическую опрерацию. В качестве поля для разделения можно использовать код транзакции или связку код пользователя + номер сессии.

[IKA]

Цитата:

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

. Будет и скорость обычной таблицы, и не нужно периодическую опрерацию.

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

[sukhanchik]

Цитата:

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

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

Он будет как минимум за счет скорости открытия формы. Да и если использовать класс RecordInsertList для вставки записей - то даже на этапе перелива уже будет выигрыш

[kair84]

2 IKA
Отпишись, сколько времени "стоит" расчет всех полей для 1 номенклатуры.
Есть вариант, при котором для большого кол-ва записей, и относительно недолгого расчета, реализовать без предварительного фильтра и с быстрым открытием.

[IKA]

2 kair84:
Форма открывается 35 секунд на приблизит 1500 записей. Не очень трагично, но неприятно.
Если отключить рассчет полей, то за 3 секунды. Именно поэтому выигрыш от переваливания все в пост таблицу в моем случае не оч очевиднен, тк все съедают именно рассчеты.
Я сделала в результате по предложенному SRF варианту InventAdjTransaction->ButtonGroup->Choose (мне все-таки кажется. что не оч грамотно написанный пример, но рабочий(помимо описанных уже вопросов про неподобающие tts и prompt, также заметила. что там врем таблица "инициализируется" на сервере не вставкой записи , а выборкой ее =) ).

Пользователи счастливы. Эта форма показывает прогнозируемые цены, рассчитываемые по местным волшебным алгоритмам. Обычно рассчеты делают на опред группы товаров, поэтому фильтр в люб случае нужен(никто махом не анализирует цены 1500 номенклатур).
Даже сейчас никто не запрещает оставить критерии пустыми, все прекрасно будет работать, только в этих редких случаях пользователь будет "морально" готов ждать.

SRF - благодарю, за ссылки на готовые примеры реализаций!

[kair84]

Цитата:

Я сделала в результате по предложенному SRF варианту

ОК
Еще в таких случаях, для успокоения пользователей, и чтоб показать что форма (или другой процесс) не просто тормозит, а что то считает, полезно выводить Progress, пользователь видит, что, что то происходит, и видит сколько это еще будет продолжаться, хотя бы примерно.