Передача датасорса в класс (пакетный режим)

[DesparioN]

Добрый день!

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

При запуске класса table.datasource() = null
Если formdatasource попытаться запаковать через array, то на prompt все останавливается без ошибок.
Пересобрать formdatasource тоже невозможно (либо я не понимаю как).
Ну и если отдельно сохранить queryRun и markRecords, то в queryRun нет возможности получить значение по порядковому номеру.

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

[Stitch_MS]

Я правильно понимаю, что вы можете собрать RecId выделенных записей и сохранить их в Set, (который легко пакуется/распакуется), не не хотите этого делать? Если да, то что не так с использованием Set-a?

[DesparioN]

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

[Stitch_MS]

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

for (custTable = _formDS.getFirst(true);
         custTable;
         custTable = _formDS.getNext())
    {

занимает слишком много времени?

Они сначала фильтруют записи в гриде, а потом кликают в верхнем левом углу, чтобы выделить всё? Тогда уж надо запрос из формы копировать, а не выделенные записи.

[DesparioN]

В общем случае функция запускается по 1-2 записям и на клиенте она отрабатывает достаточно быстро.
Но раз в определенный промежуток времени выделяется большой объем (последний раз было более 100к).

Хотелось сделать единый входящий параметр и максимально уменьшить время ожидания пользователя.
Просто раз это можно делать на клиенте, то подумал что и на сервере должно быть не сложно.

[Stitch_MS]

Цитата:

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

... выделяется большой объем (последний раз было более 100к)...

Каким образом? Что конкретно делает пользователь руками, чтобы выделить 100к записей?

[DesparioN]

"сначала фильтруют записи в гриде, а потом кликают в верхнем левом углу, чтобы выделить всё"

[sukhanchik]

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

[DesparioN]

Понятно, что есть альтернативные варианты решения.
Меня заинтересовало можно ли в каком то виде передать именно formdatasource.

[Stitch_MS]

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

[gl00mie]

Цитата:

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

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

Если вас так волнует, что пользователи будут ждать заполнения Set на клиенте, не давайте им вообще выделять записи через Grid - пусть запускают нечто (периодическую операцию, например) и через штатный механизм фильтрации (кнопка Выбор, расширенный фильтр, все дела) отбирают записи, подлежащие обработке. Крыжить записи на форме - это для случаев, когда записей мало, а критерии выбора трудно формализуемы. Если пользователи отфильтровывают записи и потом выделяют их все, то это - избыточный шаг, они даже не видят все записи, которые хотят обработать, потому что на форму для отрисовки Grid тянется лишь несколько десятков записей из выборки.
Выделять все записи для обработки через Grid - это все равно что слать в СУБД запрос на выбор 100500 записей, получать их по сети, потом куда-то там сохранять их уникальные идентификаторы, передавать их обратно по сети в СУБД и слать запрос "обнови как записи вот с такими идентификаторами таким-то образом". Так ведь никто с СУБД не работает - все стараются сразу послать запрос "обнови таким-то образом записи, которые удовлетворяют таким-то критериям".
Тем более это актуально в случае пакетной обработки: обычно форму клиент открывает на одном сервере, а пакетная обработка запускается на другом, и между ними нужно передать данные, что именно следует обрабатывать. В этом плане запаковать запрос с критериями фильтрации проще и быстрее, чем запаковать Set/Map с идентификаторами каждой записи.

Если же записей обычно немного, то посмотрите на штатный подход передачи их с формы в класс-обработчик - FormLetter::getFormRecord().