[hibernate-dev] Redefining inheritance mapping, and why to follow same rules as ORM

[Thomas Kuhlmann]

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