[Koha-bugs] [Bug 20334] Elasticsearch - Option for escaping slashes in search queries

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Mon Feb 18 16:16:57 CET 2019


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20334

--- Comment #35 from David Gustafsson <glasklas at gmail.com> ---
Yes, that change would perhaps be pretty trivial. Still not completely obvious
how to try to "autocorrect" the regexps though. The regexps in lucene are
always anchored according to
https://stackoverflow.com/questions/34312196/elastic-search-query-string-regex

That might be the reason why I got strange results when trying out regexps on
the format "foo/bar/", which produced no results, while /foobar/ did. I also
assume that the regexp is run on the tokenized values in ElasticSearch, with
possible stemming, n-grams etc applied (even though I don't think we do any of
these at the moment), so it's not very obvious for the user what values are
actually matched against. Regexp against a ".raw" subfield behaves more like
you would expect, matching against the exact value of the mapped data. I's
because of theses issue I think it might be better to disable regexps
altogether, possibly with a an option for enabling a less accessible syntax for
expert users who know what they are doing. Slashes embedded in word characters
are also interpreted as regexp by Elastic since the string "foo/bar" also
results in an error. So I also believe it to be a real problem that librarians
will input such strings with matching and/or not matching delimiters and get
unexpected results.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list