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