Hi Marc,
yes there is a degree of "smartness" in such logic, it attempts to use
the dirtyness information provided by the ORM and will skip indexing
operations if no field is changed among those which affect the index
state.
This is rather conservative, so the optimisation is disabled if there
are custom bridges on the involved entities as in that case we can't
safely relate the set of dirty fields to the index state.
As ultimate defense, if this is causing some undesired behaviour you
can disable it globally: see the hibernate.search.enable_dirty_check
configuration property in the documentation.
Sanne
On 21 May 2014 18:07, Marc Schipperheyn <m.schipperh...@gmail.com> wrote:
> I couldn't find a test on this and I'm wondering if with a structure with
> on the one hand @IndexedEmbedded(includePaths={"id","someField"}) and on
> the other hand @ContainedIn, there would be a reindexing triggered of the
> embedded element if "someOtherField" was changed at the root element (but
> not any of the indexedembedded paths). In other words, is @ContainedIn
> "smart"?
>
> Marc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
