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@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org&gt;: > 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@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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >