Please apologize me to reply to this discussion although I am not a hibernate-developer.
I created issue "HSEARCH-1656", because I have some entities at different points in my entity hierarchy (thus with different super-classes), but all those entities (and only those) should be indexed by hibernate-search. The have all the same fields to be indexed (including embedded index) and the (not so small) index-configuration is always the same. Of course, I can solve this, be adding the necessary annotations to each of those entities, but I do not like redundancy, so I had the idea of using an interface there. I really do not have any idea how much effort it is to implement such feature. I just can say, it would be useful to me (and maybe to others ...). If you send me some entry point to the code (e.g. a class or method) for that topic I will take a look on the code for myself ... . Thomas > I am really really not in favor of handling annotations from interfaces. > As you hints, it creates a *massively complex* set of rules on > overridability and inconsistent usages. > We might be able to solve them but how many months of work for what > reward? I'd rather implement free-form entity and leave it open for > someone to try that super duper max inheritance rule set of death. > BTW ORM does not inherit annotations from interfaces. > > If you expect all subclasses to be provided to you by the system > bootstrapping Hibernate Search we can offer subclass indexing. > As you say, it will be working in ORM. > I don't think it would in Infinispan as we don't know how to add to the > same hierarchy but that's another story. We could do best effort (even > though it's more unpredictable). > Your idea of reusing Jandex won't quite fully work when people put their > classes in different jars. > And funnily enough, I don't think Hibernate ORM let's you save a > subclass of an @Entity that is not itself annotated with @Entity (or > itself have a subclass annotated @Entity). > > In short, not to annotations on interfaces. > Neutral on indexing subclasses with the understanding that we are doing > it as best effort but that will remain flaky. The ability to index the > @IndexedEmbedded actual type instead of the static type seems to have > more merit to me. > > Emmanuel > > On Thu 2014-08-21 14:50, Sanne Grinovero wrote: >> First some context, we have issues open such as : >> = HSEARCH-1656 - Recognize annotations from implemented interfaces >> = HSEARCH-249 - Inheritance of annotations >> = HSEARCH-1231 - Discuss if @Indexed annotation should not be >> inherited by default >> >> I've always felt it odd that we would ignore subtypes for @Indexed >> entities, but when mentioned I got excellent counter-arguments. >> Nowadays though I've mostly forgotten why we don't, and I'm wondering >> if those arguments still stand, especially as our position to issues >> like: >> >> HSEARCH-383 - Hibernate Search does not respect the @AccessType >> annotation in respect to @Id fields. >> >> is that we don't necessarily follow the same rules as Hibernate ORM. >> Also we're currently aiming at more flexible models, not least as >> needed by protobuf encoded models like in Infinispan Query, but we >> want of course to be consistent for users of Hibernate ORM. >> >> So questions: >> >> #1 Why don't we assume subclasses of an @Indexed entity is indexed as well? >> >> A comment in HSEARCH-1231 points out that this would need classpath >> scanning, but >> a) If it makes sense we should JFDI, or explore Jandex superpowers to help. >> b) I'm not sure anymore that we need that: in the ORM use case users >> won't be allowed to run CRUD operations on unknown entities anyway, so >> I think it's safe to assume that any entity passed to Search has been >> known by ORM (and passed to us at bootstrap). Am I wrong? >> >> The question stands for non-ORM use cases, but for example Infinispan >> Query needs to apply on-the-fly registration of new types as needed >> already: not a new problem there. >> >> #2 Is HSEARCH-1656 a good idea? >> >> I find the idea fascinating, but we'd need to apply strict validations >> against the usual problems of multiple inheritance. Many of our >> class-level annotations do not allow repetitions and we'd need to >> evaluate each of them to see if they would be valid if you "inherit" >> multiple of them. >> For example, multiple @ClassBridge annotations could result in a >> composition, but things like @DocumentId shall not be repeated, and I >> wonder if we should allow conflicting fieldname writes. >> >> Other annotations are supposed to represent a function (having a >> unique answer), like @AnalyzerDiscriminator: currently we mandate to >> have only one of them, which keeps things simple and understandable; >> if I have multiple discriminators defined (one on each interface), >> would you expect the function to be applied independently on the >> @Field(s) defined by that interface? >> As someone defining different (independent) interfaces I would expect >> that, as I might not know about someone putting both (more) interfaces >> on a single concrete implementation, and probably the other >> annotations of each interface are expecting that specific >> AnalyzerDiscriminator to be applied to them. >> >> #3 Are #1 and #2 unrelated? >> >> I suspect they are not, IMHO if we do inheritance of annotations, >> inheriting them from interfaces is the next natural and consistent >> step. Or not? >> So it would be important to evaluate their link before committing on >> either, as it seems both have consequences. >> >> #4 Any example of inconsistent experience for ORM users to handle our >> inheritance "differently"? >> >> *differently* is a biased term though as it suggests some violation of >> least surprise, but actually as a user myself and as I think suggested >> by various other users as well, while the ORM rules are clear this >> missing inheritance in Search seems to have been a surprise to many. I >> suspect people understand the two things are quite different and we >> should pick a consistent rule (like decide to reject HSEARCH-383 ?) >> >> >> Thanks a lot for any feedback, >> Sanne >> >> >> https://hibernate.atlassian.net/browse/HSEARCH-1656 >> https://hibernate.atlassian.net/browse/HSEARCH-249 >> https://hibernate.atlassian.net/browse/HSEARCH-1231 >> https://hibernate.atlassian.net/browse/HSEARCH-383 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at 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
