Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiOGJhZGU2... ) / Improvement ( https://hibernate.atlassian.net/browse/HSEARCH-3476?atlOrigin=eyJpIjoiOGJ... ) HSEARCH-3476 ( https://hibernate.atlassian.net/browse/HSEARCH-3476?atlOrigin=eyJpIjoiOGJ... ) Make re-use of predicate/sort/fieldtype easier and safer ( https://hibernate.atlassian.net/browse/HSEARCH-3476?atlOrigin=eyJpIjoiOGJ... ) Change By: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Currently, predicates/sorts /etc. can be re-used by calling {{.toPredicate()}}/{{toSort()}} /etc. on the terminal context in the DSL. The user gets a {{SearchPredicate}}/{{SearchSort}} /etc. instance that can be reused in multiple queries, even in different threads. But, there are rough edges: # {{SearchPredicate}}/{{SearchSort}} /etc. are not *actually* immutable. They internally store the builders that were used by the DSL, so if you keep a reference to the DSL contexts around, you should be able to change the builders, and thus the {{SearchPredicate}}/{{SearchSort}} /etc. Maybe we should somehow "freeze" the builders when we build the {{SearchPredicate}}/{{SearchSort}} /etc. , so that trying to call a method on the DSL after that will trigger an exception? # - When reusing a {{SearchPredicate}}/{{SearchSort}} /etc. , we do not check that the search target is compatible with the one the objects were originally created for, beyond the usual technology check (Lucene/Elasticsearch). For example if you create a {{SearchPredicate}} while targeting the index {{book}}, then you re-use it while targeting the index {{user}}, something will eventually go wrong, but we won't detect it. Maybe we should? Ideally, when a {{SearchPredicate}}/{{SearchSort}}/etc. was created with a target A, and is reused in a target B, we should make sure that B is a subset of A. If we do that, worst case, the fields referenced in the predicate/sort/etc. do not exist, but if they do we are sure they are compatible. - => This is no longer true, we do check that the same indexes are targeted. # The DSL contexts can also be reused. They shouldn't be, because they reference objects that are no longer useful once the predicate/sort/etc. is built and should be garbage-collected, but everything will work if you just store the DSL contexts somewhere and re-use them. Maybe we should prevent that somehow? This is less critical, however, since it's mostly about memory consumption. ( https://hibernate.atlassian.net/browse/HSEARCH-3476#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-3476#add-comment?atlOrigin... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100129- sha1:b514962 )