Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiZDg1OTNj... ) / New Feature ( https://hibernate.atlassian.net/browse/HSEARCH-4796?atlOrigin=eyJpIjoiZDg... ) HSEARCH-4796 ( https://hibernate.atlassian.net/browse/HSEARCH-4796?atlOrigin=eyJpIjoiZDg... ) Take into account immutable properties/types when resolving dependencies for reindexing resolvers ( https://hibernate.atlassian.net/browse/HSEARCH-4796?atlOrigin=eyJpIjoiZDg... ) Issue Type: New Feature Assignee: Unassigned Components: mapper-orm, mapper-pojo-base Created: 08/Feb/2023 00:15 AM Fix Versions: 7.x-backlog Priority: Major Reporter: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) This inference would mostly help avoid cases where Hibernate Search cannot build a reindexing resolver because it cannot invert paths to dependencies. E.g. in this model: @Entity class IndexedEntity { @ManyToOne @IndexedEmbedded @Immutable private ContainedEntity contained; } @Entity @Immutable class ContainedEntity { // No association back to `IndexedEntity`! @FullTextField private String name; // No other indexed field } The user would normally get a nasty error because ContainedEntity has no inverse side for the association, preventing us from performing reindexing resolution when e.g. name changes. If Hibernate Search could understand that all indexed-embedded fields in Contained are immutable, and so is the contained property in IndexedEntity , then it could skip collecting those dependencies at bootstrap, and would not fail on bootstrap. We would essentially get a behavior similar to applying @IndexingDependency(reindexOnUpdate = ReindexOnUpdate.NO) on IndexedEntity#contained. Similarly, with this model: @Entity class IndexedEntity { @ManyToOne @IndexedEmbedded private ContainedEntity contained; } @Entity @Immutable class ContainedEntity { // No association back to `IndexedEntity`! @FullTextField private String name; // No other indexed field } … if Hibernate Search understood immutability, we could essentially get a behavior similar to applying @IndexingDependency(reindexOnUpdate = ReindexOnUpdate.SHALLOW) on IndexedEntity#contained , because contained can change but none of the indexed-embedded fields can. See https://github.com/hibernate/hibernate-orm/discussions/6090 ( https://github.com/hibernate/hibernate-orm/discussions/6090 ) for a discussion of the (many) complex concepts involved. That might give us hints as to how we can detect that a type/property is immutable. Note we could consider other sources of information regarding immutability than Hibernate ORM metadata. E.g. records are supposedly always immutable, so are primary and boxed types (int, Integer, …), and there may be some standard annotations to declare immutability (not sure about that last one though). One other thing to consider: we could accept that a bridge does not declare dependencies when it’s applied to a property/type which is “deeply immutable”, i.e. is itself immutable and only refers to immutable types. ( https://hibernate.atlassian.net/browse/HSEARCH-4796#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-4796#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#100214- sha1:6795dbd )