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

[Sanne Grinovero]

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