[hibernate-dev] adding a binding to a boolean method in Search's @Field to enable/disable

Hardy Ferentschik hibernate at ferentschik.de
Mon Feb 22 07:28:15 EST 2010


Hi,

I am not convinced yet about this feature request. My my concern is the  
annotation
"spike" Sanne already mentioned.

Our current approach covers most use cases and there is always a class  
bridge to
solve the border cases. Personally I find a class bridge not too  
complicated to handle
and it can be used in combination with the "normal" @Field annotation, so  
that you only
have to deal with your special case in the class bridge.

The suggested approach of adding a simple boolean to the class is  
definitely a too
specific solution. @DynamicField maybe, but we should not rush into  
something, given
that there are apparently other changes coming up (Infinispan requirements)

--Hardy

On Mon, 22 Feb 2010 09:01:27 -0300, Sanne Grinovero  
<sanne.grinovero at gmail.com> wrote:

> I'm not sure how easy it would be to rewrite the query backwards (you
> mean targetting the other entity in the relation right?) as he
> mentions this is a simple example from a more complex schema which
> nests deeply.
>
> About my case: last year when we implemented DynamicBoost, which is
> similar; I was actually needing only three levels of boosting I could
> have declared three fields with same name and different Boost, and let
> the entity choose which one to enable. This would have worked also to
> select an Analyzer instead of the Discriminator and who knows what's
> going to be useful next.
>
> We could solve all dynamic-X needs at once having a method which
> returns all parameters defined on Field, like @DynamicField ?
>
> ValueObject(fieldname, Store, Index, TermVector, Analyzer, Boost,
> FieldBridge) getField(value, entity, fieldName);
>
> maybe we should work out a more consistent and general solution,
> there's a spike in the numbers of annotations which is making this
> mapping too complex.
> The general idea is that a single @Field is not very flexible but is
> fine most of the time, and a ClassBridge is so flexible that it has
> you to write lots of code; maybe we should introduce a way to
> manipulate (wrap/customize/override) the DocumentBuilder you prepare
> by reading the static annotations, it's doing the right thing 99% of
> time and then it's silly that to customize the 1% you have to throw it
> away and use the fully-handcoded ClassBridge, which is error prone and
> has tight coupling to the entity.
>
> Just sharing some thoughts; will think more about it also in
> consideration of fully dynamic mapping needed for Infinispan.




More information about the hibernate-dev mailing list