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

[Emmanuel Bernard]

Yes makes sense.

On 23 oct. 09, at 21:32, Sanne Grinovero wrote:

> 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
>>
>>