On 27 Jan 2014, at 14:46, Guillaume Smet <guillaume.smet(a)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