Open bdesouza opened 3 months ago
It makes sense to me, wdyt @ellnix?
In any case @bdesouza feel free to open a PR ❤️
I'm not opposed to it. As it stands, I still think I prefer having a hash so each search has something that can identify it. Using that algolia example I would prefer:
res = client.multiple_queries({
'categories' => { indexName: 'categories', query: my_query_string, hitsPerPage: 3 },
'sponsored' => { indexName: 'products', query: my_query_string, filters: '_tags:promotion' },
'results' => { indexName: 'products', query: my_query_string, hitsPerPage: 10 }
})
And then allow for hash-like access of individual searches:
res[:categories].each do; end # ... render categories
res[:sponsored].each do; end # et cetera
If you have any other requests or ideas, please let me know. I'll be ready to implement this @bdesouza
Description Presently, the feature restricts users to a single search operation per index. However, in scenarios involving a Single Table Inheritance model within Rails, there arises a need to execute multiple searches within the same index, each with distinct filter criteria.
The crux of the matter lies in the structure of our input data, which revolves around objects. As such, attempting to define the same key more than once becomes an issue. For example:
In this instance the first query would be overwritten by the second and result in only one query.
In the ideal world we'd want to emulate what Algolia's rails implementation for multiple_queries