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.grinov...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
