Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search results using postgres full-text search #2007

Open
DerekLudvika opened this issue May 8, 2024 · 1 comment
Open

Search results using postgres full-text search #2007

DerekLudvika opened this issue May 8, 2024 · 1 comment

Comments

@DerekLudvika
Copy link

Describe the bug
In Ludvika we previously used postgres full text seach with QGIS webbklient to make the search more user friendly, for example the search will return results for "badplats" even if you type in "badplatser". The search can include multiple search attributes in a single search "document".
https://www.postgresql.org/docs/current/textsearch.html

I have implemented our existing search functions fine in origo-server by updating the search query string in pgdefault.js, however in origo-map it appears that a search result must include the actual search string in order to display the results in the list (I guess it is to do with highlighting the search string in the search results?)

To Reproduce
Ludvikakartan: https://karta.ludvika.se
A search for "Carl" works fine
https://karta.ludvika.se/origoserver/search?q=Carl
However a search for "Carl 2" fails even through origo-server returns valid results:
https://karta.ludvika.se/origoserver/search?q=Carl%202

Expected behavior
It would be good if origo-map still displays the search result even in this case even if there is no text to highlight in the search list

@steff-o
Copy link
Contributor

steff-o commented May 14, 2024

It's because search statically initilizes Awsomeplete with

 awesomplete = new Awesomplete('.o-search-field', {
   minChars: minLength,
   autoFirst: false,
   sort: false,
   maxItems: limit,
   item: renderList,
   filter(suggestion, userInput) {
     const { value: suggestionValue } = suggestion;
     return suggestionValue.toLowerCase().includes(userInput.toLowerCase()) ? suggestionValue : false;
   }
 });

Where the culprit is the filter property. If the search is performed on a server Awesomeplete should trust the response from the server without filtering again. It is acheived by configure filter: ()=> true. Not sure why this is done, it looks pretty similar to the default contains case insensitive filter that Awesomplete uses.

Don't know if it should be a configuration or if could be the new default to just trust the server's response. Safest bet is to make it opt-in, but most likely no one will suffer if it always trusts the server.

Highlighting is another process and does only affect how the suggestion looks visually, so most likely there will be no highlight, but that's correct as the actual sting used to search is not present in the result. There is a possibility to override the highlight algorithm, but I'm not sure what to highlight when the string is not found...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants