There is no magic about using the fields. I do not associate the filter with a given field. Only in context do I enable a set of tools to specify field names by the way the query was asked. Including additional parameters in annotations extend the definition possibilities. I just follow the use case in real conditions. As I presented the case. The filter works dynamically if the price is master or the price is a child of another entity. Practically, the proposed solutions are dictated by real needs. I showed here the entire use case in the product search engine, according to the price available to the user. Obviously, it is also aimed at coughing, but I see that it should not be associated with the filter only as an additional function in the predicate. If they work like that, they will only have some real usefulness, not for me. Otherwise it's just as you mentioned it will be a piece of code that is not useful to anyone. I am currently pulling several projects and I want to use hibernate-search in all of them, so I can define my real needs. Ultimately, I can handle patches, because hibernate cheeses are too valuable to give up, but not everyone can do patches. So I share my goals, keeping in mind that I'm improving your work.