Still letting it percolate :)
On Fri, Jul 22, 2016 at 11:35 AM Emmanuel Bernard <emman...@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 <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
