Foutmelding bij jump to-optie in zoekresultaten (Republic)

[joddens]

Ik typ in de vrij zoeken balk 'Amsterdam' in.

Ik krijg 40977 resultaten

Ik zet de 'resultaten per pagina' op 100

Ik houd dan 410 pagina's over.

In het veld onderaan typ ik 250 in want ik wil naar pagina 250 (daar was ik gisteren gebleven).

Dit werkt wel, maar ik krijg deze melding:

Dit lijkt me geen probleem met heel hoge prioriteit, maar ik meld het wel even.

[BasLee]

Heeft te maken met de limiet van 10k resultaten in ElasticSearch.
We kunnen ES configureren om meer te laten zien, maar welke effecten dat heeft, weet ik zo niet? @hayco
We kunnen er ook een duidelijker foutmelding van maken?

# Gaat goed:
curl -s 'https://broccoli.tt.di.huc.knaw.nl/projects/republic/search?indexName=republic-2024.09.19&fragmentSize=100&from=9999&size=1&sortBy=_score&sortOrder=desc' -X POST -H 'Content-Type: application/json' --data-raw '{"text":"amsterdam","terms":{},"date":{"name":"sessionDate","from":"1576-01-10","to":"1796-01-03"},"range":{"name":"text.tokenCount","from":"0","to":"66000"}}'

# Gaat fout:
curl -s 'https://broccoli.tt.di.huc.knaw.nl/projects/republic/search?indexName=republic-2024.09.19&fragmentSize=100&from=10000&size=1&sortBy=_score&sortOrder=desc' -X POST -H 'Content-Type: application/json' --data-raw '{"text":"amsterdam","terms":{},"date":{"name":"sessionDate","from":"1576-01-10","to":"1796-01-03"},"range":{"name":"text.tokenCount","from":"0","to":"66000"}}'

[hayco]

Tsja, die meer dan 10k lopen we af en toe tegenaan. ES kán het dan wel, maar is daar natuurlijk totaal niet voor gemaakt. Eigenlijk is 10k vragen al onzinnig vanuit ES perspectief.
Alles omgooien en zo'n "export" model maken waarbij je met een point-in-time door de hele collectie loopt is het alternatief. Is ook "meh" (maar misschien de enige optie om vanuit TAV wel door ALLES heen te kunnen lopen).
De 'scroll api' die je nog tegenkomt in oudere stack-overflow suggesties is overigens deprecated en het gebruik ervan wordt door ES afgeraden.
ES is 'gewoon' gemaakt om net als Google snel de top resultaten te laten zien. Niemand(?) gaat op Google alle pagina's af met een keyword. Je gaat dan je search verfijnen en opnieuw zoeken, als de top niet geeft wat je wil. In die zin zijn bestaande search engines als ES iets minder geschikt voor de use case dat je de hele dataset wilt doorlopen. Verfijnen van de query (en daarmee het aantal resultaten indammen) is de norm.
En ES "even overnieuw maken" zodat het wel goed geschikt is voor het opvragen van duizenden en duizenden resultaten, dat zie ik ons ook niet doen.
Als iemand werkelijk door alle duizenden resultaten heen wil lopen, dan ligt een programmatische aanpak misschien meer voor de hand. Dus dan kom je uit bij bijv. Python scriptjes die zelf door AnnoRepo en TextRepo heen gaan, wellicht. Hier zouden we nog eens een mooie boom over kunnen opzetten.
Dus, als het écht moet, dan moet er stevig tijd in worden gestopt en dan kunnen we met die "PIT" aanpak het voor elkaar krijgen. Daarvoor moet het hele search gebeuren redelijk op de schop. Want als we het 'simpel' met de pagination API doen, dan krijg je dit soort waarschuwingen:

If a refresh occurs between these requests, the order of your results may change, causing inconsistent results across pages.

en caveats:

Elasticsearch uses Lucene’s internal doc IDs as tie-breakers. These internal doc IDs can be completely different across replicas of the same data. When paging search hits, you might occasionally see that documents with the same sort values are not ordered consistently.

Wel dapper dat @joddens al 250 pagina's x 100 resultaten 1-voor-1 heeft doorgewandeld. 😅

[svandaalen]

Voor de volledigheid verwijs ik hier ook even naar #123.

[joddens]

@hayco dat ik gisteren bij 250 was gebleven was een hypothetische situatie... Alle resultaten doorlopen is zeker iets dat ik zou kunnen hebben doen, maar waarschijnlijk niet met 10.000 resultaten, dus in die zin zal dit probleem zich waarschijnlijk zelden voordoen en moeten we er nu niet al te veel energie aan verspillen.