[hibernate-dev] Clever dirty checking for Hibernate Search

[Sanne Grinovero]

2011/1/17 Emmanuel Bernard <emmanuel at hibernate.org>:
> We can experiment with such approach but I am not sure that will work properly. Here are a couple of issues:

Yes I just tossed the idea on the table, not sure either how far it
can get, but if it worked it would be a pretty nice API.

>  - what about entities exposing data via fields
I hoped someone from this list could answer that. I'm understanding
that field access won't prevent clever bytecode processors
to detect access, but I don't know how far Hibernate goes in this
direction. I think we could make it, but I'd prefer to explore these
possibilities if Hibernate Core already had something similar to
trigger dirtyness of properties.

>  - what if I poll data from an outside source and need that to be refreshed even if I do not change nor read the entity (there is one such example in Hibernate Search in Action (the available stock example).

Right, we can't do much in this case. As always, we'll provide an
option to hard-disable such optimizations both globally and at entity
level.

Sanne

>
> On 15 janv. 2011, at 11:15, Sanne Grinovero wrote:
>
>> 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
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>