[hibernate-dev] 6.0 - Type redesign

[Emmanuel Bernard]

I am eager to see what you think of my third option in my email. I dread
there is a technical blocker somewhere but it would be quite a nice
solution if that's not the case.

On Fri 2016-07-22 14:59, Steve Ebersole wrote:
> 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.