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

Hardy Ferentschik hibernate at ferentschik.de
Sat Oct 24 10:43:04 EDT 2009


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.


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?

More information about the hibernate-dev mailing list