[hibernate-dev] Clever dirty checking for Hibernate Search
Sanne Grinovero
sanne at hibernate.org
Sat Jan 15 05:15:26 EST 2011
Context:
As a follow-up on "HSEARCH-361 Only index an entity if an indexed
property has changed":
during development of this improvement we agreed to disable the
dirty-checking optimization in case a BoostStrategy or ClassBridge was
defined on the class;
we also considered the (unlikely) possibility that a FieldBridge could
access the full entity in some way, getting access to properties we
wouldn't expect (this case requires to disable the new feature).
So to fully support proper dirty check,some ideas where proposed to
add some way for ClassBridge/BoostStratey/... to define from which
properties they are affected.
Even if these implementations could list all property names, there are
drawbacks:
1) it breaks DRY. It's error prone, people could easily forget to
update the used-properties definition after fixing the main method.
2) doesn't take into account branches in the implementation. Maybe in
some cases it's affected by A,B, in some others by A,C depending on
the value of A.
3) pollutes all existing APIs.
Considering these drawbacks, I'm wondering if instead of the entity we
could pass to these implementations a proxied entity which could
record exactly which properties are being accessed.
The index would be not considered dirty if accessed properties aren't,
so further Document processing can be skipped.
I'd expect Hibernate core already has all required elements to
intercept and track access to managed entities?
Cheers,
Sanne
More information about the hibernate-dev
mailing list