[hibernate-dev] 6.0 - Type redesign

[Steve Ebersole]

Still letting it percolate :)


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

> 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.
>