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