[hibernate-dev] A fine grained way to mark @Transient and @ClassBridges as dirty

[Hardy Ferentschik]

Hi Marc,

you bring up an interesting topic. For me this is related to a whole bunch of outstanding 
issues, especially when it comes to a way to optimize how ClassBridges work.

The issues I am referring to are :

* https://hibernate.onjira.com/browse/HSEARCH-764
* https://hibernate.onjira.com/browse/HSEARCH-904
* https://hibernate.onjira.com/browse/HSEARCH-436 (no related directly, but falls for me into the same category)

We have been for a long time discussing of how we can get the class bridges to report which properties are 
affected by a particular implementation. Having such a feature would then open up the doors for  a more concrete 
dirty checking when it comes to class bridges. 

We have been discussing several potential strategies, but I don't think we really we agreed on anything yet.
Personally I would like us to find solutions for these issues first. You can then also solve your use case with
a custom class or field bridge w/o paying the penalty of that the entity is always treated as dirty. Personally,
I would prefer this type of solution over mangling Transient into the picture as well.

--Hardy


On Jun 22, 2012, at 6:28 PM, Marc Schipperheyn wrote:

> @Transient @Field and @ClassBridges mark methods and classes dirty by
> default because there is currently no way for HSearch to know which fields
> are managed here. In the case of @Transient @Field this will often be ok,
> because it will only lead to some superfluous extra indexing which is not a
> big hit on performance. However, a ClassBridge will mark all objects of a
> certain class as dirty and especially with Lazy connections, this can lead
> to a flurry of unnecessary database calls and indexing actions. Also with
> @Transient @Field this can occur when underlying Lazy connections are
> initialized.
> 
> HSEARCH-1093 talks about a way to improve this by indicating to HSearch
> which fields are actually managed by the Field (or ClassBridge) so as to
> prevent unnecessary invocations. I'm curious about ideas on this. Could
> this be an attribute, such as includePaths that overrides a default
> @Field(managedFields={"user.id"})
> @ClassBridge(managedFields={"user.id","description"})
> 
> or could it be an annotation
> @DirtyAware(value={"user.id","description"})
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev