https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33407
--- Comment #15 from David Cook <[email protected]> --- (In reply to Nick Clemens (kidclamp) from comment #14) > This is only removing punctuation surrounded by spaces, if the terms are > quoted, it won't be removed. We don't have unit tests that confirm that. Only one test was added for one particular scenario. Note that this query string isn't tested without QueryAutoTruncate in the unit tests... > It is difficult here to balance between exact results and meeting user > expectations. I worry we are getting a bit confusing as we massage the > queries more, but we still have user complaints about the over exactness of > some features in ES I am concerned about the massaging of queries. Could you give some examples of the over exactness? I have found it interesting needing to do 'local-number:"1"' instead of 'local-number:1' but I've adapted. > Looking over this one again, it seems the problem only does occur when > QueryAutoTruncate is enabled - so possibly the regex should be surrounded by > a checked for this pref? That would minimize the scope of the 'magic' here It looks like the $truncate variable there is set by QueryAutoTruncate. But since QueryAutoTruncate is on out of the box, we can think of this as default behaviour. It can be tough to change things away from defaults. -- Our main issue with Elasticsearch is timeouts/inconsistent indexing and not a lack of compatibility in a number of areas (like date searching). I can't say wildcards/truncation has really been an issue. It's interesting though. Much left to investigate and improve... -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://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/
