Feature request: annotering av flere felter for å auto-generere søkeindeks

[eNordheim]

Vi har i dag flere endepunkter hvor vi har et behov for å kunne tilby et fritekst-søk på flere felter. Et system som enkelt lar oss annotere flere felter med noe som @searchable for å hurtig utvide/endre hvilke felter som skal inngå i en søkeindeks hadde vært særdeles hjelpsomt.

Det typiske usecaset er søk som gir treff på både kode og navn/beskrivelse - gjerne i forbindelse med andre predefinerte filtre. Frontend har et stort behov for å liste opp en rekke entiteter i comboboxer slik at brukerne kan gjøre et raskt fritekst søk og få treff på entiter som de deretter vil koble til andre entiteter.

[alf]

Hei @eNordheim! Vi har begynt å tenke på dette og lagt tankene i et backlog-element: R427 (roadmap/relevance-ranked-search.md):

https://github.com/sikt-no/graphitron/blob/claude/graphitron-rewrite/roadmap/relevance-ranked-search.md

Det er en tanke-fangst, ikke en ferdig spec, men vi har allerede avdekket noen ting som er verdt å dele:

Vi ser dette som to funksjoner, ikke én:

1. Filtrering på flere felter (treff på både kode og navn/beskrivelse). Dette er i hovedsak ergonomikk: graphitron kan allerede uttrykke det via @condition i dag, så et @searchable blir hovedsakelig en måte å fjerne boilerplate for det vanlige "match kode ELLER navn"-mønsteret. Denne halvdelen komponerer fint med eksisterende filtre og beholder keyset-paginering.

2. Relevanssortering er den egentlig manglende biten, og den er vanskeligere. En god rangering (ts_rank, trigram-similarity()) er en verdi databasen regner ut, gjerne via den samme indeksen større tabeller trenger. Vi kan ikke gjøre det ærlig i Java-resolveren uten å dra alle kandidatrader inn i minnet, så relevans må være et DB-uttrykk. Graphitron sin rolle blir å navngi og rute mot det, ikke å eie en rangeringsmodell.

To prinsipper vi holder fast ved:

• Graphitron endrer aldri databaseskjemaet. Vi lager ikke tsvector-kolonner eller GIN-indekser, det eies av deres migreringer. Graphitron kan bare referere eksisterende DB-objekter ved navn (på samme måte som @order(index:) allerede gjør for sortering).
• Det brukervendte skjemaet skal være stabilt uansett fysisk strategi: enten et felt er dekket av naiv ILIKE (liten tabell) eller en indeksert tsvector/trigram-spørring (stor tabell), ser frontend nøyaktig samme SDL.

En nyanse rundt paginering: keyset-paginering (som @asConnection bruker) fungerer ikke for relevanssortering, fordi en relevansscore regnes ut per spørring, ikke er unik og ikke kan "søkes forbi". Vi ser det ikke som at søk bryter arkitekturen, men at graphitron trenger en andre pagineringsstrategi (rangert offset), der vi beholder Relay-kontrakten (edges/pageInfo/"load more") men lar cursoren bety en offset internt, med en deklarert maks-dybde.

Ett spørsmål tilbake til deg som styrer hvor mye maskineri vi faktisk trenger: I comboboks-tilfellet, blar frontend seg dypt gjennom et stort rangert resultat, eller holder det med topp-N (f.eks. de ~20 mest relevante)? Svaret avgjør om vi trenger full offset-paginering på den rangerte varianten eller kan holde det enklere.

Ikke noe hastverk med svar, dette er tidlig fase. Vi tar det videre mot spec når de åpne spørsmålene i R427 er avklart.

---

Generated by Claude Code

[eNordheim]

Hei Claude / @alf !

For comboboks-caset holder det sannsynligvis med topp-N, eksepelvis høres "~20 mest relevante treff" som et fornuftig antall, kanskje til og med litt mer en nødvendig. Vi ønsker ikke nødvendigvis at brukerne våre skal bla for mye i comboboxene, det burde heller fungere slik at de bruker søket aktivt for å begrense valgmulighetene sine. Vi vil ha andre "tabellsider" som lar brukerne "browse" det komplette datasettet.

[alf]

Takk for avklaringen, veldig nyttig tilbakemelding. Basert på dette så jobber vi nå med et forenklet design som bør være relativt enkelt å få på plass.

Et viktig veivalg vi har tatt er at vi legger opp til å støtte søk som en egen mekanisme som vi ikke blander med filter-/pagineringsfelt. Dette følger av at relevanssortering og kolonnesorterering/filtrering er forskjellig nok til at vi ikke ønsker å blande dem i første runde. Dette innebærer at eksisterende felter fungerer nøyaktig som i dag, mens søk blir egne genererte felt som tar en søkestreng (pluss eventuelle filtre) og returnerer de N mest relevante treffene, uten paginering. Dette bør fungere godt for bruksmønsteret du beskrev.

Grunnen til at vi skiller dette er at søk/relevanssortering er en tyngre operasjon som må gjøres i databasen. Dette krever andre typer indekser og funksjonalitet i databasen enn man bruker for normal filtrering/sortering.

Hvilke felter søket dekker må med andre ord bestemmes i databasen og kan ikke påvirkes av øannoteringer i skjemaet. Graphitron sin jobb er å gjøre det enkelt å ta i bruk denne funksjonaliteten slik at når jobben i databasen er gjort så blir dette trivielt.

Vi vurderer fortsatt alternative indeksløsninger, men uansett hva vi lander på kommer dokumentasjon med ferdige migrasjonsoppskrifter osv, så jeg tror det skal gå ganske fort å komme i gang med å teste dette ut i praksis.

Vi melder fra her når det nærmer seg noe dere kan prøve.