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 <emman...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev