Thank you for your feedback. So if I understood correctly you would need to: 1. Add/alter query parameter in the HTTP request (in your case, the search_type parameter). 2. Alter the path of the HTTP request (in your case, the targeted indices). Two other use cases we had in mind were: 3. Altering the JSON of the request, for example to add suggesters. 4. Parsing parts of the JSON response, for example to retrieve the value of the suggestions. That would allow to take advantage of features that are not (yet) supported by Hibernate Search, without having to build the whole request yourself. I'm not so sure about the second one (altering the path): I suspect a deeper integration would be better. For example we could make Hibernate Search aware of the aliases, maybe even manage them: that could be useful for hot updates, see HSEARCH-2861 Open . But that's a much larger problem, so maybe just providing some hook to alter the path would be enough as a first step. Just so we can understand the problem better: why exactly do you need the search query to target aliases or special indices? What do you use aliases for? Note that you could get a behavior roughly equivalent to "_all" by targeting Object.class instead of MyEntity.class when creating your query. |