Summary: | Problems with search for dateaccessioned (ElasticSearch) | ||
---|---|---|---|
Product: | Koha | Reporter: | trevor.diamond |
Component: | Searching - Elasticsearch | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | nick |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: | Bug 39630: WIP - Index 'Date' fields as a date type in Elasticsearch |
Description
trevor.diamond
2025-04-14 16:36:09 UTC
So to search for a specific date, the syntax should be: date-of-acquisition,st-date-normalized=2015-01-05 And that works in my testing. Ranges don't seem to work: date-of-acquisition,st-date-normalized=[2015-01-05 0 2016-01-05] I think because of escaping as what is passed is: '(date-of-acquisition:\\[2015-01-05 2016-01-05\\])' and those slashes may be the issue Created attachment 187397 [details] [review] Bug 39630: WIP - Index 'Date' fields as a date type in Elasticsearch This patch adds a 'date' format to the field_config and makes sure this is used for fields marked as Date in the ES config Currently 'Date' fields are indexed as standard and get keyword and text variations in ES - these field types cannot be used for range searching, so, will we try to build range queries correctly, they will not return results. TO DO: We currently escape the brackets when building a range query, i.e.: '(date-of-acquisition:\\[2015-01-05 2016-01-05\\])' This does not work, we need to pass the brackets as brackets to allow ranges to work correctly This is actually worse than initially expected, as the field is not being indexed as a date it is tokenizing each part of the date, year, day, month, as a separate token. This means a search for acqdate:2025-09-28 matches a record with three items with accessiondates: 2025-01-01, 2024-09-01, 2023-01-28 (In reply to Nick Clemens (kidclamp) from comment #3) > This is actually worse than initially expected, as the field is not being > indexed as a date it is tokenizing each part of the date, year, day, month, > as a separate token. > > This means a search for acqdate:2025-09-28 matches a record with three items > with accessiondates: 2025-01-01, 2024-09-01, 2023-01-28 Does this default "OR" operator for the tokens apply to all the searches from the advanced search? Just this one? |