Доброго времени суток!
Обычные формы, платформа 8.3.10.2772. Хочу сделать предзагрузку данных в кэш чтобы выводить информацию из кэша при обработке события ПриПолученииДанных табличного поля СправочникаСписка. Как получить строки которые находятся выше и ниже текущих получаемых из ОформленияСтрок?

Наверное надо получить текущую сортировку и запросом получить ПЕРВЫЕ выше и ниже первой и последней строки с такой же сортировкой

(1) А можно исходную задачу озвучить?

(0) По хорошему никак. Порядок строк в списке зависит от фильтров/сортировки/иерархии. В теории можно всё это разробрать, собрать запрос и попытаться вычислить следующие строки, но лучше пересмотреть идею кеширования. Что кешируем то?

(0) городилово какое то

(2) Юзер открывает форму подбора товара, нажимает на сортировку по наименованию, вводит первые символы наименования и ему отображается часть товара, начинает листать вниз и происходят зависания потому что ПриПолученииДанных выполняются тяжелые запросы. Оптимизировать запросы не вариант, все что можно уже выжал. Поэтому и хочу получить сразу 100 строк вниз например.

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

Размер справочника какой - может целиком в кэш?

(3) фильтр и сортировку не проблема получить, а текущий каталог как? проверить включен иерарх просмотр и получить текущего родителя любого товара из ОформленияСтрок?

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

(6) 200 тыс. товаров, для каждого товара надо отображать 5 типов цен, остатки с 4 складов и 4 свойства

(8) первое что сделал сказал что вы страдаете херней давайте поиск по частям слов, зачем искать глазами? в итоге переубедить не получилось - это привычка выработанная в течении 6 лет работы...

(9) Всё перечисленное можно весьма оперативно получать из текущих итоговов. Возможно, что всё таки есть ещё что выжать из запросов. На крайняк можно всё это рассчитывать фоном/регламентом и помещать в какой-нибудь регистр сведений для быстрой выборки.

(7) Из ОформленияСтрок никак, но можно получить всё это из свойств табличного поля СправочникаСписка.

Я уже давно не занимался обычными формами. А нельзя ли игнорить часть "ПриПолученииДанных" путем обработчика ожидания? Т.е. откладываем расчет полей на обработчик ожидания с задержкой 0.1, а в обработчике вызывает обновить ТП и уже обрабатываем "ПриПолученииДанных" нормально?

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

(11) Усё выжато, это прям вот в серверный модуль отправляются параметры, а там происходит анализ количества товаров для которых нужно получить, если товар один то "=" если массив то "В", а потом пакетом выбираются и подготавливаются данные. Скорость выполнения тестировали в консоле замером производительности. Насчет регистра это слишком фундаментально.

(13) то есть ПриПолученииДанных добавляем обработчик ожидания и в него засовываем обработку ОформленияСтрок? шило на мыло мне кажется, все равно будут запросы и ожидание

когда то давно - лет 5-8 назад обсуждалось
при листании сбрасываем обработчик ожидания, как прекратили листать - срабатывает обработчик и вызывает ПриПолученииДанных

у меня в моих темах где то есть и хорошее решение там есть

как искать только в своих темах - я хз )

Проще (14).

(14) Так заполняться 200 тыс долго будет, а остатки неплохо бы обновлять.
(17) Норм идея, а зачем искать - добавить флаг, поднимать в обработке ожидания, при опущенном ПриПолученииДанных - возврат. Вроде всё просто

(21) да какой то затык был, в теме решение было без затыков

(21) ну хз, пару милисекунд, не долго

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

Как-то так.

(23) Засунуть результат запроса в 200 тыс строк в кэш-соответствие - 2 мс?

(16) Костыль попроще:
- Показыыать в списке только то, что надо.
- Вычисляемые данные текущей строки показывать в отдельном окне через обработку ожидания активизации

(25) да

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

(15) Звучит как попытки самостоятельно решить кодом 1С проблемы, которые должна решать СУБД. Может тогда для скорости стоит наоборот убрать немного "оптимизаций"?
(16) Разница в том, что для пользовователя список "не лагает". Лагают только колонки с остатками товаров. Да и запросов становится значительно меньше, т.к. остатки получаются не каждый скролл, а только в момент остановки.

(27) 200к строк по 100 байт это 20МБ. Только передать их через гигабитную сеть на клиент - 160 мс, а данные ещё надо прочитать и обработать средствами (медленной) 1с на клиенте. Может мы всё таки про секунды говорим, а не про мс?

(30) Какой в жж..у клиент на оф ? Все тупо сидят в терминале на одном сервере.

(31) т.е. продолжаешь утверждать, что запрос на 200к записей с 13 соединениями(9 из которых с виртуальными таблицами) можно выполнить за 2 миллисекунды. Можно железо озвучить вашего "терминального сервера"?

(32) древний ксенон 5699, гигов 160 оперативки, рейд на серверных ссд под систему и отдельно на базы

5690

(33) тестить будем)?