On 27 Jan 2014, at 14:46, Guillaume Smet <guillaume.s...@gmail.com> wrote:
> I don't think a test would be useful to understand what we do. Here > are a few additional information about our business case. Not sure. I think it always helps to see the whole picture. > 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 > @IndexedEmbedded relation. It seems to me you were relying on some side effect of ContainedIn. AFAIK @ContainedIn has always been intended to be the counterpart to @IndexedEmbedded, not as a general reindexing trigger. That’s also what the docs imply imo. For me @ContainedIn used in an entity X means, that the entity Y owning the other side of the associations needs reindexing when X changes, because because the index of Y contains embedded fields from X. You seem to see @ContainedIn as a general trigger to reindex the other side of the association no matter what. I kind of see your use case, but if we go down your path, I think we also need to clarify the intention of @ContainedIn > In one of our (many) examples of this usage, we have: > ProductModel > @ContainedIn > Set<ProductArticle> articles; > > 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. So how does get information of the changed ProductModel into the ProductArticle? > 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 > property. Hmm, ok. > 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 > transient method…). Ok —Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
