Søgning på matrikel
KDALifa opened this issue · comments
Hej
Vi oplever fejl ved denne søgning på matrikel:
https://api.dataforsyningen.dk/rest/gsearch/v1.0/matrikel?q=1%20a&token=*******************&srid=25832&limit=10
Søgningen er: "1 a".
Retunerer en fejl:
Andre gange får vi en 504 fejl ved samme kald:
Umiddelbart kommer der en unødig fejl tilbage.
Vær opmærksom på at jeg har fjernet vores token fra eksemplet.
Yderligere oplever vi en uhensigtmæssig "fejl" ved det resultat der kan komme tilbage fra en søgning:
Ved søgning på f.eks. "egholm" får vi dette resultat:
"Egholm Ø" bliver valgt før "Egholm" eller "Egholm," hvilket resulterer i at brugerne ikke får de resultater de forventer.
Hvis der blevet skrevet "egholm," kommer der de resultater frem som der forventes.
I søgningen bør fritstående "egholm" blive søgt efter før "egholm ø", alså "egholm ø" skal ikke komme som det første resultat når der søges efter "egholm".
MVH
Karsten
Egholm er en duplikering af #28 issue.
Tak for at indmelde CORS fejlen, vi kan ikke replikere issuet men vi har lavet en ændring i opsætningen der forhåbenlig betyder den ikke kommer igen.
Det er korrekt at i får 504 da kaldet 1 a svarer til en søgning 1 AND a.
Hvordan skal vi behande en søgning som består af "1 a", hvis brugeren bare er lidt for langsom til at skrive sin søgning?
PT. kommer der en decideret fejl "504 Gateway Timeout" tilbage, hvilket i vores verden er helt fejlagtig, hvis den ikke kan finde noget, skal det vel være 0 i resultatet, og en status 200? for kaldet er jo ok, men der er bare intet data.
Jeg kan også berette at CORS fejlen stadig består.
I får 504 gateway timeout fordi et kald med "1 a" tager 12 - 13 sekunder at returenere, men vores timeout er sat til 10 sek.
Vi har https://github.com/SDFIdk/gsearch-ui der er et eksemple på implementering af API'en med typeahead søgningen. I er velkommen til at bruge den som inspiration.
Hej
Selv om en request timer out, fordi den sikkert ikke kan finde data? så bør i nok se på hvad der sker, behandlingen af sådanne simpel søgning er ikke hensigtsmæssig.
Jeg vil da gerne se jeres eksempel, men umiddelbart ligger problemet i servicen og ikke kaldet fra klienten. Det nytter jo heller ikke noget vi bare ignorer de fejl der bliver sendt retur.
Yderligere så overholder vi jeres krav der er stillet med hensyn til at sende en url encoded streng, så hvis i ikke kan håndterer en søgning på "1 a" så er det jeres problem og ikke vores.
I får request timeout fordi der er for meget data. Så en søgning er 1 a er en bredere søgningen end API'en er designet til da gsearch ikke er lavet med henblik på store udtræk.
Vi tager højde for visse små søgetekster f.eks. vil søgningen a gå meget hurtigt og kommer tilbage med en simple sortering.
Selv om der er for meget data, så er håndteringen stadig ikke tilstrækkelig fra jeres side, vi overholder de krav der er sat, og i retuner en fejl som peger på at jeres server fejler.
Hvornår kan vi vide om det reelt er en server fejl hos jer, eller at det er jeres rest api som ikke kan håndterer en simpel søgning?
Vi har set på jeres dokumentation endnu engang, og vi overholer alle de krav der er sat, desuden er der ikke beskrevet at der kan komme en response af 504 på matrikelsøgning, der er kun angivet 200.
Jeg forstår godt jeres vinkel på problemstillingen.
Gesearch er et typeahead søgeinterface som søger i en række datasamlinger.
Datasamlingerne er forskellige i forhold til de features der typisk er interessante for brugerne at søge på for adresser er det vejnavne og nummer for matrikel matrikelnummer og ejerlav og for andre er det noget helt andet.
Det giver udfordringer og uundgåelige trade offs i forhold til at optimere søgninger.
Den søgning der er tale om her er en søgning på ét tal ét mellemrum og ét bogstav – den søgning giver så mange resultater at Gsearch ikke kan nå at samle data og sende det til klienten inden for en 10 sekunders timeout grænse
Hvis man i stedet søger på 1a – altså uden mellemrum får man et resultat på få sekunder
Det er fordi matriklen står som 1a og ikke 1 a i databasen
Servicen returnere korrekt http fejlkode 504 som er en timeout – hvis service returnere http kode 200 kunne man i klient enden tror at der blot var tale om et tomt resultat.
Det er vigtigt for os at vi sender korrekte http returkoder således at klienterne kan indrettes til at reagere hensigtsmæssigt på en fejl.
Vi forstår godt problemstillingen men vi har ikke i den nuværende version af Gsearch mulighed for imødekomme jeres behov for at kunne søge med et mellemrum mellem tal og bogstav uden at andre søgninger vil falde uheldigt ud.
Vi arbejder løbende på at udvikle Gsearch og jeres input er meget værdifuldt for os og vi har et ønske om at kunne hjælpe jer og jeres kunder til en god oplevelse.
Vi er i færd med at planlægge næste version af Gsearch og jeres input vil indgå i den proces