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

Sanne Grinovero sanne.grinovero at gmail.com
Fri Oct 23 13:52:02 EDT 2009


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



More information about the hibernate-dev mailing list