[hibernate-dev] 6.0 - Type redesign

[Steve Ebersole]

Some preliminary thoughts are inline.  Like I said in the earlier reply I
am still trying to distill this in total.

On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> The good news is that I am following you :D
>
> I think one of the option is some API to which you can pass the (JPA)
> Type, a Path from root and it would return a structure qualifying the
> embedded info and not just the embeddable.
>
> I'm making things up here
>
> //might not even need the type, could be guessed from the Path?
> AttributeMapping am = mappingProvider.forPath(path);
>
> What's nasty is that it then requires two parallel APIs, or rather it
> would not flow from an enhanced JPA type API.
>

Yes, this is more or less one option I had considered... at least the
general approach is the same.  Basically 2 separate, parallel ways to
describe attribute/mapping info.

However, that said, even Path (assuming you specifically
mean javax.persistence.criteria.Path) includes the "context" we need; it
has to ultimately be rooted back to a root (#getParentPath) with mapping
information: we cannot build a Path rooted at an embeddable.

So to further define these 2 "separate, parallel" models:

   1. Type would only ever deal with the generic model information (aligned
   with JPA) by Attribute.  Meaning this simply describes the domain model -
   more or less, obviously it does expose some simplistic persistence data
   points like inheritance-type, singular attribute "classifications", etc
   mandated by the JPA contracts.
   2. The idea of a "mapping model" would more follow this Path/Binadable
   model.  This would be the purpose of persisters and its exposed
   "MappedAttributes"

Yes, it would be much nicer if we could combine these models/concepts, but
I think the JPA model is just too limited to allow that.


An alternative would be what I think you propose with the BindableType,
> that is an extension point that describes the specifics of the
> specialization when navigating from one node type to another. I think.
>

Yes, and no.  Based on that break-down above - BindableType would just be
things that can be part of a Path.  In fact, in JPA Bindable/BindableType
has no correlation to its Type.  Bindable simply unifies things that can be
part of a query Path which could be either:

   1. an EntityType
   2. a SingularAttribute
   3. a PluralAttribute

This distinction is great because it happens to line up with how we see
this mapping information (with the assumption that a "root" can only ever
be the first - an EntityType).  So I'd slightly alter this list to say that
Bindable can be either:

   1. an EntityType*
   2. a SingularMappedAttribute
   3. a PluralMappedAttribute

(*) - can be root.

The idea of "MappedAttribute" would essentially be a composition of

   1. Attribute
   2. MappedAttributeContainer - extension of Bindable

I think that Path will not work for modeling since Path is specifically a
query concept and could be circular.