Динамический список и поиск... неприятностей
Разработка - Работа с интерфейсом
Это я потом понял, что всему виной была моя гиперактивность. А как хорошо всё начиналось - обработки работают, солнышко к горизонту клонится, обмен себе знай пыхтит, через хмл-конвертацию данные грузит... Дёрнуло же меня полезть смотреть навскидку выбранный элемент справочника. Чисто для спокойствия. Открыл я, значит, параллельный сеанс базы, нашёл уже прогруженный ранее справочник.
Да, товарищи. Справочником этим была "Номенклатура". Очень такой солидный, немаленький объём данных.
И что сделал типа умный я? Набрал в поиске, который услужливо торчит в форме списка, свои заветные несколько буковок. Цензурных, ясное дело. Но 1С обиделась. Совсем. Потому что стала громко пыхтеть, жрать все ресурсы, какие я мог пронаблюдать, и вообще изображать мировую катастрофу типа "мы все умрём". И умерла через повешение.
Быть палачом и вешателем мне, конечно, не хотелось, поэтому взгрустнул и задумался, это что ж такое я зацепил ненароком? Форма списка в той конфе простая, без закидонов, права и РЛС в норме, запрос у динамического списка кошерный, т.е. соединений со всякой ересью не содержит. Железячные ресурсы тоже, в общем, адекватные, ERP тянут. Архитектура, все дела - не на что грешить.
Тут у читателя возникают вопросы - а) что это за конфа, б) что стряслось. Конфа - BAS для Украины, по сути локализованная УТ с доработками; а что именно стряслось - мне тоже стало интересно, взял лопату и принялся за изучение.
Динамический список, для чистоты эксперимента, я сунул на отдельную форму внешней обработки. В такое мы, крутые разрабы, все умеем) Дальше мысль пошла в сторону настроек оного списка, а это СКД.
Дыра это нора, нора это Кролик...
СКД это настройки отбора, отбор это иерархическая коллекция, смотреть отладчиком - печальненько, поэтому сделал свою функцию. Чтобы все вложенные уровни сразу, текстом, весомо-грубо-зримо.
Поиск, как мы все знаем, кончается именно отбором. А уж вытащить отбор, имея дело с динамическим списком, адски сложное дело типа такого:
ТекстДокумент=Новый ТекстовыйДокумент;
Настройки=Элементы.Список.ПолучитьИсполняемыеНастройкиКомпоновкиДанных(); // это штатный метод платформы
ПостроитьСтроковоеПредставлениеОтборов(Настройки.Отбор, ТекстДокумент); // это моя процедура, если чо
А потом я этот "ТекстДокумент" на клиенте смотрю глазами.
Ииии..
Допустим, я юзверь и хочу найти зверя в базе животных. Шиншиллу, например. Потому как всё происходящее - очень пушной зверёк. Вот и будем искать по первым четырём буквам.
Дальше я проиллюстрирую, что происходило. Я вбивал буквы, ставился отбор, и смотрел, что в настройки СКД напихано - конкретно, в настройку отбора. И вот что получилось.
Сразу стало понятно, что добрый механизм платформы ищет по всем строковым реквизитам. Разумеется, и по неиндексируемым. И в случае справочника - и по тем, что для групп, и по тем, что для элементов. И по наименованиям ссылочных реквизитов. Группой "ИЛИ". Видом сравнения "Содержит". Везде.
Хорошо хоть, числовые да булевы, да всякие там гуидные, не припахивает. Правда, если внимательно посмотреть, то на значения перечислений устанавливается отбор "В списке", и списки эти пустые. И ещё вообще пустые группы отборов. Ну... есть многое на свете, друг Горацио, что пропустил дебаг при компиляции...
Ага, подумал я, щас мы его. И поотключал видимость колонок.
Поскольку крутизна пёрла из ушей, я вспомнил про флаги "Использовать всегда" и "Получение представлений для невидимых полей". И - о ужас! - оказалось, что ровно никакого влияния на работу этого поиска-отбора они не оказывают.
Далее я сделал произвольный запрос. Он уже порадовал больше.
А ещё добавим-ка веселья полей, которые разыменуют (т.е. через точку) те, что в списке. И добавил - и в режиме Конфигуратор, и в режиме Предприятие, через волшебную "Изменить форму". Натурально, опять забабахал поиск.
А потом я ещё поиграл с видимостью колонок. И понял: единственный фактор, влияющий на наложение отбора - видимо поле или невидимо.
Супер, подумал я, созерцая картину. А ведь есть ещё разные другие поиски. Как они ищут, родимые?
Всё оказалось лучше, чем могло быть:
Правда, эти поиски могут накладываться один на другой. Тогда это выглядит примерно так:
Одновременно установленный "расширенный" поиск и поиск по Ctrl+F
[V] Наименование Содержит *ШИНШИЛЛА {Строка}
[V] Ссылка В группе из списка {Позиция номенклатуры}
[V] ГРУППА ИЛИ
[V] Наименование Содержит шинш {Строка}
[V] Код Содержит шинш {Строка}
[V] Артикул Содержит шинш {Строка}
[V] ГРУППА ИЛИ
[V] ВесЕдиницаИзмерения.Наименование Содержит шинш {Строка}
[V] КодДляПоиска Содержит шинш {Строка}
и тормозит хотя и не столь люто, но изрядно. Имеем верхнее условие по "И".
Одного не знаю - ставится ли отбор на поля неограниченной длины, если их колонки видны в списке. Проверять не тянет, и так кошмары ночью снятся.
В общем, самым прожорливым ресурсоёмким оказался поиск, завсегда каждому доступный. Потому что отбор, генерируемый им, кромешная жуть с точки зрения производительности. Вот оно, смотрите и бойтесь помните:
Мораль: каждый раз, когда юзер вбивает свои поисковые хотелки в это проклятущее поле, где-то в мире плачет одна Патти Сэлинджер. И злобно хохочет один БГН)
А если кто хочет добавки, то вопрос на самостоятельный разбор: у таблиц значений в формах тоже есть поиск. Такой же. Как же он-то себя ведёт?..
Если вам понравилось, то могу рассказать ещё изрядно страшных сказок из повседневной практики)))
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
