Arvados

Updates at b93675913 - branch 15429-wb1-use-trigram-search
Test run: https://ci.curoverse.com/job/developer-run-tests/1590/

• Replaced to_tsquery() with to_tsquery_filters() that adds a ["any", "ilike", "%term%"] for every "word" on the user search query.
• No test updates needed as integration tests don't care how the search is done.

Some clarification needed: On to_tsquery()'s comment there were some cases documented stating that underscore chars should be treated as non-word, but from my manual tests it seems that isn't the case with the current regular expression. Not sure if the comments were old or the code buggy and I should add that feature to the new function.

Since it's no longer doing tsquery things, to_tsquery_filters() doesn't seem like the best name -- maybe ilike_filters()?

""." is a word char in FT queries" → "...ilike queries"

comment "It returns null if..." → "It returns [] if..." (good change!)

to_tsquery_filters(q).forEach(function(f) { filters.push(f) }) ...could be just filters = filters.concat(to_tsquery_filters(q)) like the line above

Updates at 13ac0cadc
Test run: https://ci.curoverse.com/job/developer-run-tests/1593/

Addressed the above comments and also renamed the to_tsquery.js file to ilike_filters.js

Retrying integration tests at https://ci.curoverse.com/job/developer-run-tests-apps-workbench-integration/1686/

Lucas Di Pentima wrote:

Some clarification needed: On to_tsquery()'s comment there were some cases documented stating that underscore chars should be treated as non-word, but from my manual tests it seems that isn't the case with the current regular expression. Not sure if the comments were old or the code buggy and I should add that feature to the new function.

I don't think it matters: the purpose of defining "word chars" in the previous code was to match the postgres full-text query behavior. The new code just has to behave sensibly with "ilike". I suppose we can either treat an underscore as a word char and leave it alone (so it matches any single char) or escape it with a backslash (so it matches a literal underscore). I'd guess that most users will expect it to match a literal underscore, but the wildcard option also seems reasonable.

LGTM @ 13ac0cadc

Escapes the "_" char so it can be used as a literal at a238ab719
Test run: https://ci.curoverse.com/job/developer-run-tests/1595/
Integration tests retry: https://ci.curoverse.com/job/developer-run-tests-apps-workbench-integration/1690/

LGTM, thanks