gorbenko.pavel/tnsu-approval-route
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: почему отчёт по вакансиям на items REST, а не на Search

Browse Source 
Разбирались, можно ли перевести чтение на 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>
This commit is contained in:
gorbenko.pavel
2026-08-28 14:10:15 +05:00
parent 1221b31225
commit c0bc73559e
1 changed files with 21 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend/Tnsu.ApprovalRoute.Application/Reports/VacancyReportService.cs
+21
View File
@@ -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 для перечисленных выше полей.
/// </summary>
public sealed class VacancyReportService(
ApprovalRouteDbContext db,