From my post on the mailing list:
Before 4.4, when you add a @ContainedIn to a property without the
corresponding @IndexedEmbedded, they were still added and taken into
account in the dependency resolution which was quite useful to declare
dependencies between entities without having an explicit
@IndexedEmbedded which are useless in some of our cases.
Starting with 4.4, they are simply ignored.
I've spent some time to understand why and here it is:
-> you can see that the @Contained is added even if there is no
In the new code, the @Contained annotation is added in
updateDepthProperties which is conditioned by the fact that there is a
I'm wondering if it's a desired change or just an overenthusiastic refactoring?
The fact is that we have complex business rules which requires us to
reindex entities when we change/index one even if they don't have an
You're right about having specific fieldbridges but we also have the
case when we want to index the results of a transient method on a
dependency of the object.
In one of our (many) examples of this usage, we have:
ProductArticle doesn't have an @IndexedEmbedded annotation on its
ProductModel field because we don't use this feature to index it. But
when we reindex a ProductModel, we need to reindex the articles.
Moreover, an article might have a ShootingBrief and when we change the
ProductModel, we also want to reindex the ShootingBriefs of the
ProductArticles as they have a field which depends on a ProductModel
This field is the result of a transient method. Not an @IndexedEmbedded thing.
Using @ContainedIn as we do allows us to build a dependency graph of
indexing. And this dependency graph exists even if we don't use
@IndexedEmbedded but other Search features (FieldBridges, @Field on a
Note that it worked perfectly until 4.4.
Should we not port this to master too?