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

Thu Aug 21 11:26:42 EDT 2014

On 21 August 2014 16:03, Emmanuel Bernard <emmanuel at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev