2011/1/17 Emmanuel Bernard <emman...@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@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
