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

[Emmanuel Bernard]

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