Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiODJiZmVh... ) / New Feature ( https://hibernate.atlassian.net/browse/HSEARCH-1937?atlOrigin=eyJpIjoiODJ... ) HSEARCH-1937 ( https://hibernate.atlassian.net/browse/HSEARCH-1937?atlOrigin=eyJpIjoiODJ... ) Consider offering a query based approach to @ContainedIn ( https://hibernate.atlassian.net/browse/HSEARCH-1937?atlOrigin=eyJpIjoiODJ... ) Change By: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Today, people need to use create an association to go from an embedded entity B to the containing entity A and annotate it with {{@ContainedIn}}. This is necessary for us to know which instance of A contains the instance of B. This is sometimes undesirable as the association is not necessary for the application. This is particularly true of ToMany associations. An alternative approach would be to let the user express a query instead of materializing an association. {code:java}@Entity @ContainedIn("from A a where a.b.id in (:listOfIds)") class B { ... } @Entity @Indexed class A { @IndexedEmbedded B b; }{code} -I think that's a not too complicated feature that can be done by a community member.- Yoann: it is complicated, because the query approach makes little sense if we don't provide a way to "chunk" reindexing, i.e. a way to retrieve a batch of entities from the query, reindex them, flush and clear the session, continue to the next batch, etc. If we don't do that, this query mechanism will only make sense for associations with a small cardinality (an association with 8000 linked entities is a no-no). But such a chunked reindexing is hard (impossible?) to implement properly: * we would ideally want it to read from the user session's cache, but never, ever write to the user sessions's cache (in particular the clear() calls should not remove entities that the user expects to be in the session). * depending on the number of entities to reindex, the reindexing process could take a lot of time. We may want to make reindexing happen in a background process instead of the user session. In conclusion, it's likely that such a feature only makes sense if we implement asynchronous processing of entity change events ([https://hibernate.atlassian.net/browse/HSEARCH-3280|https://hibernate.atl...]). Since integrating the two features would likely require API changes, I'd rather work on this ticket after [https://hibernate.atlassian.net/browse/HSEARCH-3280|https://hibernate.atl...] is solved. We might want to abstract away from a query string and use an interface / implementation so that Hibernate Search working in non ORM environment can still benefit from this approach. I haven't thought much about this abstraction. ( https://hibernate.atlassian.net/browse/HSEARCH-1937#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-1937#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#100217- sha1:fd7c927 )