Your example would work. Another option that would have the benefit to not use scripts (that often slow down queries if many documents match) would be to do something like this:
The problem with the 1st option is the performance only if the list is too long, isn't it?
I know there will not being more than 30 documents or something like that
Is there any other options? I would like a succint one if possible giving the fact that, in my opinion, that the multiple exact values query don't give back the response in order is a bug or at least is has no sense
There will indeed be performance issues if the list is long. But also if many documents match since the script will need to be called on every matching document, and Groovy scripts typically have some constant overhead. But if you know for sure there will never be more than 30 matching documents, this will be totally fine.
No, I think I will not have this issue since I'm asking for documents that can't share path and slug (so if the list is 3 elements long the response will be 3 documents long)
What about the issue that being list and array were the order matters the query is returning a non ordered response?
What sense makes this? Remember that the query is called Multiple exact values (exact)
This is no bug to me: the order in which results are returned is defined by the value of the sort parameter (which defaults to sorting by descending score). And the terms query gives a score equal to 1 to all matching documents, so documents will come in an order which is not specified. When dealing with multiple terms, the way to go if you want to give different weights to your terms is to use a bool query and then combine the scores using boosts for simple use-cases or function_score for more complicated use-cases.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.