[hibernate-dev] about HSEARCH-367 : Support only one kind of Similarity per index

[Sanne Grinovero]

No Similarity is not being read from configuration files, just the annotations.
Current behaviour already throws an exception if two/more entities
from the same class hierarchy define a different Similarity, but in
this case it's considered acceptable to define it once for all
involved types;
actually this is inconsistent too, as I could define a different type
in a subclass and we're actually using it for the whole hierarchy -
not only the subclass as I could expect.

Shall I open an issue to be able to define Similarity in configuration
files for 3.3 ?

2009/10/23 Emmanuel Bernard <emmanuel at hibernate.org>:
> Warnings are useless IMO, I would raise an exception if you find
> inconsistencies.
>
> Doesn't a similarity configuration exist at the index (property) level
> already? If not, I agree, this would make more sense to me.
>
> On 23 oct. 09, at 19:52, Sanne Grinovero wrote:
>
>> I'm looking into this as it's blocking way too much other stuff,
>> it's not hard to implement but is having me puzzled about usability.
>>
>> Basically I'm planning to throw an exception when different entities
>> are defining a different Similarity while sharing the same index.
>>
>> This case is obvious:
>> @Entity @Similarity(ImplA.class) @Indexed(name="oneindex")
>> A
>> @Entity @Similarity(ImplB.class) @Indexed(name="oneindex")
>> B
>>
>> so I'll throw an exception.
>>
>> What about this case:
>> @Entity @Similarity(ImplA.class) @Indexed(name="oneindex")
>> A
>> @Entity @Indexed(name="oneindex")
>> B
>>
>> ?
>> This would be fine for me, and I would use ImplA Similarity for index
>> "oneindex" (being applied to both entities A and B), but it's looking
>> bad to not warn about the inconsistency.
>> I think some confusion can arise, imagine the situation in which I'm
>> adding the similarity definition to entity A, I wouldn't expect it to
>> make effect also on entity B.
>>
>> The confusion arises IMHO from the fact being in Hibernate Search
>> there's a notion of "index configuration", so there's an index
>> "entity" (as a concept) to speak about,
>> while the definition of the properties of this "index" is scattered
>> about the @Indexed at Entity(es) and the configuration properties.
>> Like when configuring sharding and IndexWriter configuration settings,
>> they are only exposed in the configuration file.
>> The similarity is actually a property of one index, so the annotation
>> shouldn't exist and it should be configured like other index settings,
>> still I agree it feels natural to declare it on an entity so I'm not
>> proposing to remove it.
>> I'm afraid there's a bit of inconsistency, but I've no clear idea
>> about how to solve it: I'm just pointing out what is IMHO a weakness
>> we should think about.
>>
>> What should I do in the above mentioned case? Log a warning? just let
>> them do? throw an exception, demanding to have all entities annotated
>> the same way?
>>
>> Regards,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>