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.
Regards,
Sanne
2010/2/22 Emmanuel Bernard <emmanuel(a)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 <emmanuel(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev