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:
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:
… 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 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. |