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,