https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33407 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed --- Comment #17 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- (In reply to David Cook from comment #15)
(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...
I added more tests for when truncate is enabled - it would be good to repeat the tests without the syspref - can we get a follow-up Janusz?
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.
The above should be fixed by bug 32707. In general, Zebra was more forgiving: without truncation 'idea' would match 'ideas' or 'ideation' 'blues' would match 'blue' Punctuation too: dont/don't matched both ways
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.
Oops, I forgot the conditional, thanks :-)
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...
Hmm...we've done a number of enhancements to the indexer to improve this and ensure smaller batches to avoid timeouts - could you open a bug with more details? -- You are receiving this mail because: You are watching all bug changes.