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. Regards, Sanne 2010/2/22 Emmanuel Bernard <emman...@hibernate.org>: > Actually isBridgeEmabled is a better name. > > On 22 févr. 2010, at 10:03, Emmanuel Bernard wrote: > >> I am not 100% certain mueller's use case is right as the query could >> probably be rewritten backward to eliminate the "flatenization" due to the >> denormalization. But you were saying that you could have used such feature >> and I was wondering about it. >> >> yes I mean isFieldEnabled(value, entity, field). It seems less intrusive to >> me than a dynamic flag on @Field or an EL. >> >> On 22 févr. 2010, at 09:54, Sanne Grinovero wrote: >> >>> Hi Emmanuel, >>> it's not my usecase, it's described in the forums: >>> https://forum.hibernate.org/viewtopic.php?f=9&t=1002800 >>> >>> You mean something like this: >>> >>> boolean isFieldEnabled(Object value, Object entity, String field); >>> >>> (having value,entity,field parameters as in Discriminator )? >>> >>> Sanne >>> >>> 2010/2/22 Emmanuel Bernard <emman...@hibernate.org>: >>>> I guess we can do like we've done for @AnalyzerDiscriminator. >>>> But can you describe your use case a bit deeper? >>>> >>>> On 22 févr. 2010, at 09:29, Sanne Grinovero wrote: >>>> >>>>> Hello all, >>>>> there's a user on Search's forum which is asking for a new feature: >>>>> >>>>> https://forum.hibernate.org/viewtopic.php?f=9&t=1002800 >>>>> >>>>> We already had cases of people wanting to enable/disable indexing at >>>>> instance level; in this case he wants to avoid indexing certain fields >>>>> in some conditions; reading a boolean property in the same indexed >>>>> instance would be good enough. >>>>> I'm unsure about the binding expression, but the idea of having each >>>>> Field enabled/disabled independently would indeed have helped me in >>>>> other situations, preventing me from writing a full ClassBridge for >>>>> just some special fields. >>>>> >>>>> Regards, >>>>> Sanne >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
