On 21 August 2014 16:03, Emmanuel Bernard <emman...@hibernate.org> wrote: > 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.
Ok, but I never implied this as higher priority than free-form. I had it optimistically marked for 5.1 but to follow your advice I've now removed any version. > 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). Problem is, this is how Infinispan Query works today: annotated types pop-up at any time dynamically and we need to deal with it. But I agree - as discussed during free-form design - that this madness should be stopped :-) Still, with the current design in Query I am clueless at how Infinispan should then provide these types upfront, I've rised the subject many times on the Infinispan mailing list and it always died without a solid solution. An idea could be to restrict its usage from not using inheritance at all, and no "entity" will share an index with another entity: after all that project is not targeting complex domain models but a key/value store, but it's not clear to me if this is an acceptable limitation. > 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). I understand that, but it doesn't limit our options? > 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. Right but that's where I'm coming from. If we index the actual type and not the one statically linked to from @IndexedEmbedded, wouldn't you expect the same behaviour on subclasses respect to @Indexed? I'm not pushing for either solution, just trying to reason about what should be considered a consistent behaviour: Hibernate Search 3.x and 4.x are *consistent* on this, so what I'm wondering now is if we should be consistent again with the choices made in this regard, or is the relation between the two far fetched? -- Sanne > > 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@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
