Разбирались, можно ли перевести чтение на Search: один KQL сразу по всем
партициям, отставание индекса отчёту не критично. На тенанте проверено
поштучным сравнением Search и REST — часть нужных полей индекс не отдаёт
вообще, хотя значения в списках есть:
• Заявка на подбор: OpenReason, OpenReasonDetails
• Прием на работу: CandidateName, HireDate, ReplacedEmployee
• — согласование: Ticket (Lookup — managed property не нашлась вовсе)
Префикс группы колонок сайта (TansuSite…) не помогает, задержка crawl тоже
ни при чём: у тех же свежих элементов рабочие поля Search отдаёт сразу.
Значит эти поля пришлось бы дочитывать построчно батчами по 100, и на 1000
заявок Search+дочитка выходит ~46 HTTP-запросов против ~5 у нынешнего REST.
В list view threshold REST не упирается by design: партиции режутся на 4900
(ListPartitioning:ItemCountThreshold), ни один $filter не сканирует больше
предела.
Кода не меняем — фиксируем разбор в doc-комментарии, чтобы вопрос не
поднимался заново. Вернуться к Search осмысленно только после того, как в
Search Schema заведут работающие managed properties для этих полей.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gorbenko.pavel
c0bc73559e