When adding 'local-number' as a fallback sort I explicitly added sorting on 'local-number' - it should be 'local-number__sort' This avoids problems when mappings may be older and local-number itself is indexed as a string and not a number
Created attachment 185441 [details] [review] Bug 40658: Use local-number__sort and not local-number directly This patch makes sure we inject the __sort form of local-number, rather than the field directly - this ensurs searching works even if mappings mayu be different and local-number itself is not numeric To test: 1 - Edit mappings.yaml and set local-number from 'number' to 'string' NOTE: There are two copies of local-number - one in auth and one in biblio - the latter is the important one here 2 - perl misc/search_tools/rebuild_elasticsearch.pl -r -v 3 - Confirm in staff interface Admin -> Search Engine Configuration that local-number is now a string 4 - Search and get an error Error: Unable to perform your search. Please try again. In the logs: [illegal_argument_exception] Text fields are not optimised for operations that require per-document field data like aggregations and sorting, so these operations are disabled by default. Please use a keyword field instead. Alternatively, set fielddata=true on [local-number] in order to load field data by uninverting the inverted index. Note that this can use significant memory. 5 - Apply patch, restart all 6 - Search again 7 - Success!
Created attachment 185447 [details] [review] Bug 40658: Atomic update to ensure local-number is sortable I don't know if this is appropriate for master as it requires Koha objects, but this is helpful for upgrading sites to avoid any problems from old mappings for local-number