From 818fb76d6137febf2b5ebd9332b9bccf6a72e093 Mon Sep 17 00:00:00 2001 From: Sebastian Frank Date: Tue, 20 Oct 2026 00:51:43 +0000 Subject: [PATCH] =?UTF-8?q?Suche:=20Hook-Ausf=C3=BChrung=20pr=C3=A4zisiere?= =?UTF-8?q?n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- plans/audit-report.json | 2 +- src/content/docs/projekt/suche.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/plans/audit-report.json b/plans/audit-report.json index 10f9cfe..08ed64d 100644 --- a/plans/audit-report.json +++ b/plans/audit-report.json @@ -1,5 +1,5 @@ { - "generatedAt": "2026-10-20T00:39:19.753Z", + "generatedAt": "2026-10-20T00:51:22.849Z", "stats": { "files": 70, "byDir": { diff --git a/src/content/docs/projekt/suche.mdx b/src/content/docs/projekt/suche.mdx index 5a90ffd..f0b3706 100644 --- a/src/content/docs/projekt/suche.mdx +++ b/src/content/docs/projekt/suche.mdx @@ -200,7 +200,7 @@ search: - Gebaut wird der Index beim Projekt-(Re-)Load aus den **gespeicherten** `_search`-Ngrammen (nie aus den Quellfeldern), damit er nicht vom MongoDB-Pfad abweichen kann. - Genutzt wird er für ngram-Quellen von `combined`-Suchen **und für Einzel-ngram-Suchen** — dort ersetzt er nur das Ranking, die Seitendokumente werden anschließend per `_id` geladen (Projektionen/`?select` wirken weiter; `?lookup=` und `?aggregate=` erzwingen dagegen MongoDB). Bei `combined` zeigt der Debug-Header `inMemory=ram|mongo(loading)|mongo(budget)|mongo(candidates)|mongo(no-terms)`; `mongo(no-terms)` erscheint nur, wenn für die Quelle überhaupt ein In-Memory-Index existiert. -- Einzel-ngram-Suchen fallen mit `X-Search-Debug: true` im Kopf `X-Search-Memory` sichtbar auf MongoDB zurück, wenn der Index nicht bereit ist oder die Anfrage etwas braucht, das der Index nicht garantieren kann: `mongo(disabled)`, `mongo(loading)`, `mongo(budget)`, `mongo(count)` (bei `?count=1`), `mongo(sort)` (bei eigenem `?sort=`), `mongo(no-terms)` — sowie `mongo(lookup)`, `mongo(aggregate)`, `mongo(hook-pipeline)` und `mongo(hook-filter)`, wenn die Anfrage Schritte braucht, die in der MongoDB-Pipeline laufen. Ein Hook, der `context.filter` zurückgibt oder in-place ändert, ersetzt den effektiven Filter samt Suchbedingung und fällt auf `mongo(hook-filter)` zurück. Ein `pipelineMod` aus einem Read-Hook stört den RAM-Pfad nur, wenn er die Ergebnismenge ändern kann (`$match`, `$sort`, `$group`, `$project`, …), Stufen vor die bestehende Pipeline setzt oder `_id`/`_search` schreibt bzw. `$_search` liest. Reine angehängte Feld-Transformationen (`$addFields`, `$set`, `$unset`) laufen auf der geladenen Seite nach der Projektion und bleiben im RAM. +- Einzel-ngram-Suchen fallen mit `X-Search-Debug: true` im Kopf `X-Search-Memory` sichtbar auf MongoDB zurück, wenn der Index nicht bereit ist oder die Anfrage etwas braucht, das der Index nicht garantieren kann: `mongo(disabled)`, `mongo(loading)`, `mongo(budget)`, `mongo(count)` (bei `?count=1`), `mongo(sort)` (bei eigenem `?sort=`), `mongo(no-terms)` — sowie `mongo(lookup)`, `mongo(aggregate)`, `mongo(hook-pipeline)` und `mongo(hook-filter)`, wenn die Anfrage Schritte braucht, die in der MongoDB-Pipeline laufen. Der Read-Hook selbst läuft einmal pro Anfrage; nur seine `pipelineMod`-Funktion kann im MongoDB-Fallback zweimal laufen (Klassifikation + echte Pipeline). Ein Hook, der `context.filter` zurückgibt oder in-place ändert, ersetzt den effektiven Filter samt Suchbedingung und fällt auf `mongo(hook-filter)` zurück. Ein `pipelineMod` aus einem Read-Hook stört den RAM-Pfad nur, wenn er die Ergebnismenge ändern kann (`$match`, `$sort`, `$group`, `$project`, …), Stufen vor die bestehende Pipeline setzt oder `_id`/`_search` schreibt bzw. `$_search` liest. Reine angehängte Feld-Transformationen (`$addFields`, `$set`, `$unset`) laufen auf der geladenen Seite nach der Projektion und bleiben im RAM. - Rollen-`preFilter`, `?filter=` und Hook-Filter gelten weiter: der Index liefert Kandidaten-IDs, die danach gegen den effektiven Filter geprüft werden. - Schreibvorgänge (Anlegen/Ändern/Löschen/Bulk/Worker/Regenerate) halten den Index aktuell; **Snapshot- und Backup-Restore bauen alle In-Memory-Zustände neu auf** (Indizes + Cache) — alte Treffer können einen Restore nicht überleben. Während des Neuaufbaus laufen Suchen auf MongoDB. - Budget-Abbruch (zu viele Dokumente, Speicher- oder RSS-Grenze) lässt den Index leer und dauerhaft auf MongoDB; ein Reload startet einen neuen Versuch.