not sure there is a reliable way. Using the Validate API output you could maybe compare the explanation, but queries like foo OR bar compared to bar OR foo would still make a difference - depends if you want that.
May I ask, what the plan or reasoning for this is? Can you share some more context of what you are trying to achieve?
I have integrate Elasticsearch into my application.
I have made different API which will filter out data accordingly.
Due to large number of APIs, I have made builder which will get me a searchRequest, which can help me in quering to the Elasticsearch.
So now I wanted to tested whether two searchRequest could be comparable without calling Elasticsearch client, because if I include Elasticsearch call into testing, then testing time will be lot more.
And one I am fetching from the method call it as searchRequestBuilder()
so it look like this:
SearchRequest actual = searchRequestBuilder(); // consider required parameter is passed
So I am doing this just because I can related with expectedString. I can run expectedString inside Kibana in Dev Tools to check I am fetching correct data. And now I want to compare this query with what I am building from searchRequestBuilder() method.
About searchRequestBuilder() method:
It builds the list of query which I can use to build SearchRequest object.
building query template looks like this:
{
"query": {
"bool": {
"must":[// Passing list of query generate by some logic],
"must_not:[//passing list of query generate by some logic]
}
}
}
I wanted to compare SearchRequest objects because I don't want to make call to Elasticsearch because it will take more time.
so I was wondering if i can compare query of both objects.
I wanted to compare SearchRequest objects because I don't want to make call to Elasticsearch because it will take more time.
So, this was the part I was searching for. Two things to keep in mind and why I am highly against such a 'caching' logic on your application side.
There is already a bit of caching logic on the Elasticsearch side to speed things up, if the same filters are used
If you have aggregation only searches, those are cached on the Elasticsearch side by default, until new data is added or modified. And you can change this behaviour also for search hits by using request caching. See Shard request cache settings | Elasticsearch Guide [8.1] | Elastic - this is a full blown caching and should return immediately, unless new data is added.
How do you handle updates in your application logic cache, as you do not know, when data is stale and have to come up with your own custom expiration process.
Hope that helps to understand my thought process and why I'd try to stay away from client side caching as long as somehow possible.
Hi Alex,
Thank you for suggesting to avoid from client side caching. I am avoiding this client side caching in my application. So when it is running, its api call goes through Elasticsearch.
But,
I forgot to mentioned that the comparison part is done in testing phase.
I am writing unit test to test if SearchRequest query are equal, So when the application is running I don't have to check the query I am building.
Also while testing, each request is different from previous request with different indexes, that's why I was trying to check If I can compare directly inside java code, instead of calling Elasticsearch.
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.