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

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.