Bug 27314 - Update default Elastic mapping
Summary: Update default Elastic mapping
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching - Elasticsearch (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Nick Clemens
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-29 15:12 UTC by Andrew Fuerste-Henry
Modified: 2023-01-05 19:42 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
ES mappings that were not included in default setup but are used by OPAC searches (1.46 KB, text/plain)
2023-01-05 19:42 UTC, Sarah Cornell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2020-12-29 15:12:28 UTC
As we've been bringing libraries online with Elastic searching, we've run into a handful of changes to the default mappings. I'm filing this bug to remind us to push some of those back into the community defaults.

I'll circle back here with details of changes we've made.

Anyone else have changes they'd like to see in the community ES mappings?
Comment 1 Katrin Fischer 2020-12-30 08:55:50 UTC
+1 I'd love to see good defaults for the libraries just starting out with Elasticseach!
Comment 2 Jonathan Druart 2021-01-07 10:52:44 UTC
Andrew, maybe we should ask the list before working on this?
Comment 3 Sarah Cornell 2023-01-05 19:42:52 UTC
Created attachment 145074 [details]
ES mappings that were not included in default setup but are used by OPAC searches

I reviewed all the searches that our OPAC generates and made sure that the fields they used were indexed. I found MANY missing indexes.  Some of the searches SEEMED okay but were not because one of the 3 fields used in the automatically generated search was missing.  So no one has to go through it again I will share the indexes I've added in an attachment.  

NB: the search that the OPAC generates that might use the 775at is still under discussion.  We're not sure which index is best when the search generated is ti,phr.