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

[Hardy Ferentschik]

Hi,

I agree with Emmauel. Warnings are too weak. I think in the case where two  
entities share the same index,
but only one defines explicitly a Similarity an exception should be thrown.

Regarding the configuration - I also feel there are several  
inconsistencies. As Sanne is saying the
problem arises from the fact there are really two concepts which are not  
clearly separated - indexed entities
vs Lucene indexes.
I guess this could have been avoided if we only had a one to one mapping  
between entity and Lucene index
(which would probably to limiting)
It would be nice to rethink the configuration, but it might imply breaking  
some backward compatibility.


--Hardy



On Sat, 24 Oct 2009 11:13:48 +0200, Emmanuel Bernard  
<emmanuel at hibernate.org> wrote:

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