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 <emman...@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 <emman...@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 @inde...@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? _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
