Suche: einheitlicher Title+Urheber+Schlagwort-Filter über gesamte WP #18

New Issue

tobias · 2026-04-08T17:43:53+02:00

tobias commented

2026-04-08 17:43:53 +02:00

Ziel

Einheitliches Suchverhalten in allen vier Adaptern (NRW, MV, BE, LSA): die Suche scannt den gesamten Datenbestand der laufenden Wahlperiode, sortiert nach Datum absteigend, filtert clientseitig nach Treffern in Titel, Urheber und Schlagwort.

Ersetzt die ursprüngliche Volltext-Strategie aus #13 (mit den Sub-Issues #14, #15) und den UI-Toggle aus #17 — die wurden alle als "deferred until uniform" geschlossen.

Begründung

Der bisherige Stand war asymmetrisch:

NRW: OPAL-native Suche (Titel + Schlagwort, server-side)
MV: ParlDok facet_fulltext=0 (echter Server-side Volltext)
BE/LSA: Quick-Win client-side Title-Filter über ein 730-Tage-Window (#13)

Folge: gleiche Suchanfrage liefert pro Bundesland völlig unterschiedliche Treffermengen, weil mal Volltext, mal Titel, mal nur ein Zeitfenster gescannt wird. Für den User ist das nicht nachvollziehbar — eine 0-Treffer-Antwort kann an seiner Anfrage liegen oder an der Adapter-Limitation, ohne dass es sichtbar wäre.

User-Entscheidung (2026-04-08): einheitliches "Title + Schlagwort über alles" ist besser als bestes-mögliches-pro-Adapter mit asymmetrischem Verhalten.

Akzeptanzkriterien

MV: ParLDokAdapter baut den facet_fulltext-Tag zurück, scannt stattdessen via Pagination alle WP8-Drucksachen und filtert clientseitig auf Title + Urheber
BE: PortalaAdapter für Berlin verzichtet auf das date_window_days-Fenster, paginiert über die ganze WP19, clientseitiger Filter wie heute
LSA: PortalaAdapter für Sachsen-Anhalt analog
NRW: keine Änderung — bleibt wie es ist (~25 prod-Assessments laufen darauf, OPAL liefert eh server-side Title-Match)
Schlagwort-Feld (Schlagworte/thesaurus/keywords) wird im clientseitigen Filter berücksichtigt, sofern im Hit-list-Output sichtbar — wenn nicht, separater Folge-Issue
Sortierung ist überall newest-first (das ist bei allen Adaptern bereits Default)
Smoke-Test pro Bundesland: /api/search-landtag?q=Schule liefert ≥10 Treffer, und die ältesten Treffer sind tatsächlich aus dem Anfang der laufenden WP

Performance-Sorge

BE hat ~3000+ Drucksachen pro WP. Bei chunksize=200 und 15 Pages dauert ein voller Scan 30-60s. Mögliche Mitigation:

pro-Suche caching der hit-list im RAM (so dass der zweite Suchbegriff den Scan nicht wiederholt)
höhere chunksize wo der Server das verträgt (bei LSA war 500 schon stabil unter 30s)
async batches statt sequenzieller Pages

Wird bei der Implementierung empirisch gemessen — wenn unzumutbar, separater Folge-Issue für Caching.

Beziehung zu geschlossenen Issues

Schließt das Loop, das #13/#14/#15 offen lassen (alle als deferred markiert, können bei Bedarf reopened werden)
Ersetzt #17 (UI-Toggle ist hinfällig wenn alle Adapter sowieso gleich verhalten)
#16 (UI-Split DB vs. Landtag) bleibt davon unberührt — der ist eine eigene UX-Verbesserung

## Ziel Einheitliches Suchverhalten in allen vier Adaptern (NRW, MV, BE, LSA): die Suche scannt **den gesamten Datenbestand der laufenden Wahlperiode**, sortiert nach Datum **absteigend**, filtert clientseitig nach Treffern in **Titel, Urheber und Schlagwort**. Ersetzt die ursprüngliche Volltext-Strategie aus #13 (mit den Sub-Issues #14, #15) und den UI-Toggle aus #17 — die wurden alle als "deferred until uniform" geschlossen. ## Begründung Der bisherige Stand war asymmetrisch: - **NRW**: OPAL-native Suche (Titel + Schlagwort, server-side) - **MV**: ParlDok `facet_fulltext=0` (echter Server-side Volltext) - **BE/LSA**: Quick-Win client-side Title-Filter über ein 730-Tage-Window (#13) Folge: gleiche Suchanfrage liefert pro Bundesland völlig unterschiedliche Treffermengen, weil mal Volltext, mal Titel, mal nur ein Zeitfenster gescannt wird. Für den User ist das nicht nachvollziehbar — eine 0-Treffer-Antwort kann an seiner Anfrage liegen oder an der Adapter-Limitation, ohne dass es sichtbar wäre. User-Entscheidung (2026-04-08): einheitliches "Title + Schlagwort über alles" ist besser als bestes-mögliches-pro-Adapter mit asymmetrischem Verhalten. ## Akzeptanzkriterien - [ ] **MV**: `ParLDokAdapter` baut den `facet_fulltext`-Tag zurück, scannt stattdessen via Pagination alle WP8-Drucksachen und filtert clientseitig auf Title + Urheber - [ ] **BE**: `PortalaAdapter` für Berlin verzichtet auf das `date_window_days`-Fenster, paginiert über die ganze WP19, clientseitiger Filter wie heute - [ ] **LSA**: `PortalaAdapter` für Sachsen-Anhalt analog - [ ] **NRW**: keine Änderung — bleibt wie es ist (~25 prod-Assessments laufen darauf, OPAL liefert eh server-side Title-Match) - [ ] Schlagwort-Feld (`Schlagworte`/`thesaurus`/`keywords`) wird im clientseitigen Filter berücksichtigt, sofern im Hit-list-Output sichtbar — wenn nicht, separater Folge-Issue - [ ] Sortierung ist überall newest-first (das ist bei allen Adaptern bereits Default) - [ ] Smoke-Test pro Bundesland: `/api/search-landtag?q=Schule` liefert ≥10 Treffer, und die ältesten Treffer sind tatsächlich aus dem Anfang der laufenden WP ## Performance-Sorge BE hat ~3000+ Drucksachen pro WP. Bei `chunksize=200` und 15 Pages dauert ein voller Scan 30-60s. Mögliche Mitigation: - pro-Suche caching der hit-list im RAM (so dass der zweite Suchbegriff den Scan nicht wiederholt) - höhere chunksize wo der Server das verträgt (bei LSA war 500 schon stabil unter 30s) - async batches statt sequenzieller Pages Wird bei der Implementierung empirisch gemessen — wenn unzumutbar, separater Folge-Issue für Caching. ## Beziehung zu geschlossenen Issues - Schließt das Loop, das #13/#14/#15 offen lassen (alle als deferred markiert, können bei Bedarf reopened werden) - Ersetzt #17 (UI-Toggle ist hinfällig wenn alle Adapter sowieso gleich verhalten) - #16 (UI-Split DB vs. Landtag) bleibt davon unberührt — der ist eine eigene UX-Verbesserung

tobias referenced this issue from a commit

2026-04-08 19:01:01 +02:00

ParLDokAdapter: Volltext (#12) deaktivieren — einheitlich Title-Filter (#18)

tobias commented

2026-04-08 19:03:16 +02:00

Erledigt mit minimaler Variante in b5ae889. Statt der ursprünglich diskutierten "Title-Suche über die ganze WP" — die mit ~5 Minuten pro Suche zu langsam war — wurde nur der Volltext-Pfad in MV deaktiviert.

User-Entscheidung 2026-04-08: "deaktiviere die fulltext suche nur".

Neuer Stand der vier Adapter

Adapter	Verhalten	Coverage	Latenz
NRW	OPAL nativ	je nach OPAL	~3-5s
MV	Title-Filter über letzte 1000 Drucksachen (10 Pages × 100)	~6 Monate WP8	25-72s
BE	Title-Filter über 730d-Window (#13 Quick-Win)	~24 Monate WP19	9-11s
LSA	Title-Filter über 730d-Window (#13 Quick-Win)	~24 Monate WP8	9-16s

Alle vier filtern jetzt clientseitig auf Title + Urheber, kein Server-Volltext mehr. NRWs OPAL-Eigensuche ist semantisch ähnlich (Title-Match-basiert), bleibt unangetastet weil sie seit ~25 prod-Assessments stabil läuft.

Live-Verifikation `Schule`

$ curl /api/search-landtag?q=Schule&bundesland=...
  MV   → 3 Treffer  (vorher 20 mit Volltext)
  BE   → 20 Treffer
  LSA  → 14 Treffer

MV ist jetzt schlechter als BE/LSA für Schul-Suchen, weil das ParlDok-Pagination-Window nur ~6 Monate abdeckt und BE/LSA über 24 Monate gehen. Bewusste Trade-off-Entscheidung.

Was nicht gemacht wurde

Kein Pagination-Ausbau für MV auf größeres Window (würde 5+ Minuten pro Suche bedeuten)
Kein In-RAM-Cache mit Lazy-Build (war als "Async Background-Suche + Cache"-Variante diskutiert, aber dann zurückgezogen)
Keine Frontend-Änderungen — /api/search-landtag bleibt synchron wie heute

Der FACET_FULLTEXT-Konstant und der _fulltext_id-Helper bleiben im ParLDokAdapter-Code als Dokumentation für die spätere Re-Aktivierung wenn die Volltextsuche wieder einheitlich werden kann (closed-as-deferred Issues #13/#14/#15/#17 enthalten die Reverse-Engineering-Findings).

Erledigt mit minimaler Variante in b5ae889. Statt der ursprünglich diskutierten "Title-Suche über die ganze WP" — die mit ~5 Minuten pro Suche zu langsam war — wurde nur der Volltext-Pfad in MV deaktiviert. User-Entscheidung 2026-04-08: "deaktiviere die fulltext suche nur". ## Neuer Stand der vier Adapter | Adapter | Verhalten | Coverage | Latenz | |---|---|---|---| | **NRW** | OPAL nativ | je nach OPAL | ~3-5s | | **MV** | Title-Filter über letzte 1000 Drucksachen (10 Pages × 100) | ~6 Monate WP8 | 25-72s | | **BE** | Title-Filter über 730d-Window (#13 Quick-Win) | ~24 Monate WP19 | 9-11s | | **LSA** | Title-Filter über 730d-Window (#13 Quick-Win) | ~24 Monate WP8 | 9-16s | Alle vier filtern jetzt clientseitig auf Title + Urheber, kein Server-Volltext mehr. NRWs OPAL-Eigensuche ist semantisch ähnlich (Title-Match-basiert), bleibt unangetastet weil sie seit ~25 prod-Assessments stabil läuft. ## Live-Verifikation `Schule` ``` $ curl /api/search-landtag?q=Schule&bundesland=... MV → 3 Treffer (vorher 20 mit Volltext) BE → 20 Treffer LSA → 14 Treffer ``` MV ist jetzt schlechter als BE/LSA für Schul-Suchen, weil das ParlDok-Pagination-Window nur ~6 Monate abdeckt und BE/LSA über 24 Monate gehen. Bewusste Trade-off-Entscheidung. ## Was nicht gemacht wurde - Kein Pagination-Ausbau für MV auf größeres Window (würde 5+ Minuten pro Suche bedeuten) - Kein In-RAM-Cache mit Lazy-Build (war als "Async Background-Suche + Cache"-Variante diskutiert, aber dann zurückgezogen) - Keine Frontend-Änderungen — `/api/search-landtag` bleibt synchron wie heute Der `FACET_FULLTEXT`-Konstant und der `_fulltext_id`-Helper bleiben im `ParLDokAdapter`-Code als Dokumentation für die spätere Re-Aktivierung wenn die Volltextsuche wieder einheitlich werden kann (closed-as-deferred Issues #13/#14/#15/#17 enthalten die Reverse-Engineering-Findings).

tobias closed this issue

2026-04-08 19:03:16 +02:00

tobias referenced this issue from a commit

2026-04-09 00:34:07 +02:00

Activate Schleswig-Holstein via StarFinderCGIAdapter (#20, Phase 2)

tobias referenced this issue

2026-04-09 00:35:28 +02:00

Scraper SH: Schleswig-Holstein (StarWeb, Wahl 2027-04-18) #20

Sign in to join this conversation.