11:28 a.m.
@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"})
7:01 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:48 a.m.
The TwoWayFieldBridge issue seems similar to what I'm suggesting and would
seem to resolve most of my issues.
11:30 a.m.
On Jun 25, 2012, at 2:48 PM, Marc Schipperheyn wrote:
The TwoWayFieldBridge issue seems similar to what I'm suggesting
and would seem to resolve most of my issues.
Then I think we should focus on this. I need to refresh my memory on where we stand in the
discussion around this issue.
--Hardy
4566
days inactive
4570
days old
3 comments
2 participants
participants (2)
-
Hardy Ferentschik -
Marc Schipperheyn