From c0bc73559e29bf20f969711b5e4839dbf9488779 Mon Sep 17 00:00:00 2001 From: "gorbenko.pavel" Date: Fri, 28 Aug 2026 14:10:15 +0500 Subject: [PATCH] =?UTF-8?q?docs:=20=D0=BF=D0=BE=D1=87=D0=B5=D0=BC=D1=83=20?= =?UTF-8?q?=D0=BE=D1=82=D1=87=D1=91=D1=82=20=D0=BF=D0=BE=20=D0=B2=D0=B0?= =?UTF-8?q?=D0=BA=D0=B0=D0=BD=D1=81=D0=B8=D1=8F=D0=BC=20=D0=BD=D0=B0=20ite?= =?UTF-8?q?ms=20REST,=20=D0=B0=20=D0=BD=D0=B5=20=D0=BD=D0=B0=20Search?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Разбирались, можно ли перевести чтение на 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 --- .../Reports/VacancyReportService.cs | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/backend/Tnsu.ApprovalRoute.Application/Reports/VacancyReportService.cs b/backend/Tnsu.ApprovalRoute.Application/Reports/VacancyReportService.cs index 9ab436a..e24e071 100644 --- a/backend/Tnsu.ApprovalRoute.Application/Reports/VacancyReportService.cs +++ b/backend/Tnsu.ApprovalRoute.Application/Reports/VacancyReportService.cs @@ -18,6 +18,27 @@ namespace Tnsu.ApprovalRoute.Application.Reports; /// /// Рекрутёра и даты закрытия вакансии в самой заявке нет — они берутся из парного /// списка «— согласование», из строк фазы «Исполнение» (см. ExecutionRow). +/// +/// ПОЧЕМУ ЗДЕСЬ items REST ПО ПАРТИЦИЯМ, А НЕ SEARCH (разбирались 2026-08-28). +/// Search выглядит уместнее — один KQL сразу по всем партициям, и отставание +/// индекса отчёту не критично. Но на этом тенанте ЧАСТЬ нужных полей индекс не +/// отдаёт вовсе, при том что в самих списках значения есть (проверено поштучно +/// через REST): +/// • «Заявка на подбор»: OpenReason, OpenReasonDetails; +/// • «Прием на работу»: CandidateName, HireDate, ReplacedEmployee; +/// • «— согласование»: Ticket — Lookup, managed property не нашлась ни под +/// одним из разумных имён (TicketOWSTEXT/TicketOWSLKID/TicketId/…). +/// Префикс группы колонок сайта (TansuSite…, см. tools/sp/README.md) тоже не +/// помогает — пробовали. +/// +/// Значит эти поля пришлось бы дочитывать построчно батчами по 100 — и на 1000 +/// заявок Search+дочитка выходит ~46 HTTP-запросов против ~5 у нынешнего REST. +/// В list view threshold (5000) REST при этом не упирается by design: партиции +/// режутся на 4900 элементов (ListPartitioning:ItemCountThreshold), то есть ни +/// один $filter не сканирует больше предела. +/// +/// Вернуться к Search имеет смысл, только если в Search Schema заведут +/// работающие managed properties для перечисленных выше полей. /// public sealed class VacancyReportService( ApprovalRouteDbContext db,