Elasticsearch is very flexible search engine and has many configuration options. We should document our expectations on how it should work and also because then it would allow the users to understand how to form their queries in the best possible way. After documenting the configuration we want based on the expectations we should tune the indexing and search configuration parameters accordingly. The bug 27070 makes the Elasticsearch searches more Zebra like by trying to match search keywords across all fields but is this exactly what we want in the end? What if we have only a number in the search query should we try to query numeric fields then only or also string fields? How should the weights work? For weight documentation we should have an basic configuration for it in our default mappings.yaml file so that we have some idea how it will be used in real world.
Some links that contain information that might be useful for the decision making: https://discuss.elastic.co/t/cross-fields-and-boost-is-it-feasible/134219/11 https://wiki.koha-community.org/wiki/Elasticsearch https://www.elastic.co/guide/en/elasticsearch/reference/master/query-dsl-multi-match-query.html https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-boost.html
Where could this documentation take place? Koha wiki? What should it cover exactly? We should stop now adding functionalities, or fine tuning an implementation which is obfuscated by overengineering.
(In reply to Frédéric Demians from comment #2) > Where could this documentation take place? Koha wiki? What should it cover > exactly? We should stop now adding functionalities, or fine tuning an > implementation which is obfuscated by overengineering. As a lot of libraries are already using Elasticsearch in production stopping the fine tuning and bug fixing appears not possible. What would you suggest?