https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20334
--- Comment #35 from David Gustafsson <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
