I started a wiki discussing the proposal for the type system redesign. Let's get discussions about it starter sooner rather than later. Thanks! https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign

Steve, I still need to look at the wiki page and will give more detailed feedback on some parts of it. One general thing coming to mind though is how support for OGM could be improved. On first thought I'd say the "Java side" of Type might stay as is, but the "SQL side" (or "datastore side") and read/write logic interacting with result sets etc. would have to look differently in the case of OGM. If this part of the story could be made pluggable somehow, than a custom factory of sorts in OGM could plug in its dedicated implementation of the "datastore side". Not sure how it'd look in practice, the implementations would be rather different (we don't work with ResultSet at all in OGM), so I suppose it might require casting to the expected subtype when working with Type in ORM or OGM. Currently, we completely override the Type hierarchy from ORM with a corresponding GridType hierarchy in OGM, but it might be possible to re-use many more code by just customizing the "datastore side". Plus, it'd be a tad more efficient for OGM, as we can skip the translation from Type to GridType. I might provide some more details once having studied the current proposal in more depth, just wanted to get out these thoughts to you. --Gunnar 2016-06-22 18:54 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > I started a wiki discussing the proposal for the type system redesign. > Let's get discussions about it starter sooner rather than later. Thanks! > > https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

Ok, I need to move forward on this and I have gotten enough affirmative feedback to ahead. On Fri, Jun 24, 2016 at 6:24 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > This is all part of the to-be-decided read/write part of the new Type > contract. I propose, as discussed in the wiki, that we have Type return > ValueExtractor and ValueBinder for read/write. So assuming that is there... > > One possible answer to your story is that OGM as a SQM interpreter and > Metamodel (persisters, etc) implementor would influence the Type and > therefore the ValueExtractor and ValueBinder. We'd just need to define the > right generic API to allow that to happen without ORM, e.g., having to jump > through a bunch of hoops to get to JDBC objects. > > On Fri, Jun 24, 2016 at 5:18 PM Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > >> Steve, >> >> I still need to look at the wiki page and will give more detailed >> feedback on some parts of it. >> >> One general thing coming to mind though is how support for OGM could be >> improved. On first thought I'd say the "Java side" of Type might stay as >> is, but the "SQL side" (or "datastore side") and read/write logic >> interacting with result sets etc. would have to look differently in the >> case of OGM. >> >> If this part of the story could be made pluggable somehow, than a custom >> factory of sorts in OGM could plug in its dedicated implementation of the >> "datastore side". Not sure how it'd look in practice, the implementations >> would be rather different (we don't work with ResultSet at all in OGM), so >> I suppose it might require casting to the expected subtype when working >> with Type in ORM or OGM. >> >> Currently, we completely override the Type hierarchy from ORM with a >> corresponding GridType hierarchy in OGM, but it might be possible to re-use >> many more code by just customizing the "datastore side". Plus, it'd be a >> tad more efficient for OGM, as we can skip the translation from Type to >> GridType. >> >> I might provide some more details once having studied the current >> proposal in more depth, just wanted to get out these thoughts to you. >> >> --Gunnar >> >> >> >> >> 2016-06-22 18:54 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> I started a wiki discussing the proposal for the type system redesign. >>> Let's get discussions about it starter sooner rather than later. >>> Thanks! >>> >>> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign >>> >> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >>

On 22 Jun 2016, at 18:54, Steve Ebersole <steve(a)hibernate.org&gt; wrote: I started a wiki discussing the proposal for the type system redesign. Let's get discussions about it starter sooner rather than later. Thanks! https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I am working on a larger response to some current challenges, but here is a quick response to your specific points... On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > BasicType does not handle multiple column and compositeType is the > mebedded case. How would multi-column types would be handled? > In terms of what exactly? Assuming you mean access to the JDBC descriptors, that is still being determined. At the moment there is no single Type-level access to this information. Each specific Type sub-interface defines access differently. I am not a fan of that that aspect. The other approach is to define a plural form on Type (Type#getColumnMappings), and BasicType would just ensure that there is just one. Why do you need to ”unscope" the TypeConfiguration? What do you gain from > it? I’m trying to picture a reuse use case? > Functionally we do not gain anything. I was just trying to be balanced. We injected the SF into the TypeConfiguration, I wanted to un-inject it as well for 2 reasons: 1. release the reference to the SF 2. prepare the TypeConfiguration for binding to another SF. The only use case I had in mind was tests where we occasionally build multiple SF instances from a single Metadata. Methods of Type needing Session: I used to call them passing null in some > old code and hoping for the best. Are the reasons for using Session still > present? Would be nice to get rid of that. > This is only ever needed (sometimes) from EntityType. I guess it depends which specific method(s) you are asking about. For some (reading, writing) yes I think we will continue to need the Session: it is used for access to JDBC as well as other needed interactions with the Session/PC (scheduling ids for batch load, etc). For other methods, maybe not. On the genericization of Type, it would be extremely nice indeed for OGM, > but it would require to genericize SqlTypeDescriptor and its methods > essentially. Not necessarily super trivial. > I understand that. It is not a primary goal for me tbh. But if we can get a decent design for the ORM case and can see an easy way to extend this to OGM without negatively impacting ORM I am all for it. Given the delegation to Binder and Extractor I think this will be doable, although I assume we will need some parameterized param object to make this work. The paam object would give us access to "JDBC services" in ORM and something else in OGM.

Put another way, I think the problem (and probably the solution) here is similar to JPA's Bindable (and Path) concept. On Thu, Jul 21, 2016 at 2:27 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > One goal of the redesign is to build more friendly, easy-to-follow > contract for access to this metadata at runtime (legacy persister state). > Rather than accessing pieces of information pertaining to attributes across > many, many arrays I wanted an array of a composite representation of these > attributes. JPA defines it this way, so on some level you'd think it would > be pretty straightforward to move this direction. The major pain-point I > have been facing is that JPA does not define "mapping information" at all > in its Metamodel/Types. The main place this comes to a head is > EmbeddableType, especially given access to it directly on Metamodel *by > class*. In JPA terms that return has to model the Embeddable (no mapping > info) rather than the Embedded. And then further when we > expose EmbeddableType's attributes we have the same problem continued > because the context/root is the embeddable rather than the embedded. > Hopefully this makes sense, but as an example consider (using a "component > safe NamingStrategy): > > @Entity > class Store { > ... > @Embedded > Address headquartersAddress; > @Embedded > Address locationAddress; > } > > @Embeddable > class Address { > String streetAddress; > @Embedded > PostalCode postalCode; > ... > } > > @Embeddable > class PostalCode { > String zip; > String plus4; > @ManyToOne > City city; > } > > Then consider that JPA frames access to this information as: > > EmbeddableType<Address> addrType = metamodel.embeddable( Address.class ); > > Because it is generic to the Address embeddable, we have no access to the > specific embedded mapping info. And if we follow this access down further, > it also means the same for accessing the attributes of that EmbeddableType<Address>. > For example, accessing the "postalCode.zip" from the EmbeddableType<Address> > we'd have no ability to resolve whether that maps to "headquartersAddress_postalCode_zip" > or "locationAddress_postalCode_zip". And of course, as an ORM we need > access to that mapping information :) > > Essentially that is the crux of the difficulty I have at the moment. > > I know we could get around this by splitting (or keeping split) the > notions of ORM Type and JPA Type, but I would like to avoid that : this > unification is going to be important to the SQM Criteria support. > > So the question becomes how to best handle exposing an "Attribute" with > mapping information as well as an "Attribute" without mapping information. > > I will be working on some proposals for ways to do this over the next week > or so. And maybe y'all see a solution easier than I do (I fear I may not > be seeing the forest through the trees atm). > > > On Thu, Jul 21, 2016 at 7:49 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> I am working on a larger response to some current challenges, but here is >> a quick response to your specific points... >> >> On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel(a)hibernate.org&gt; >> wrote: >> >>> >>> BasicType does not handle multiple column and compositeType is the >>> mebedded case. How would multi-column types would be handled? >>> >> >> In terms of what exactly? Assuming you mean access to the JDBC >> descriptors, that is still being determined. At the moment there is no >> single Type-level access to this information. Each specific Type >> sub-interface defines access differently. I am not a fan of that that >> aspect. The other approach is to define a plural form on Type >> (Type#getColumnMappings), and BasicType would just ensure that there is >> just one. >> >> >> Why do you need to ”unscope" the TypeConfiguration? What do you gain from >>> it? I’m trying to picture a reuse use case? >>> >> >> Functionally we do not gain anything. I was just trying to be balanced. >> We injected the SF into the TypeConfiguration, I wanted to un-inject it as >> well for 2 reasons: >> >> 1. release the reference to the SF >> 2. prepare the TypeConfiguration for binding to another SF. >> >> The only use case I had in mind was tests where we occasionally build >> multiple SF instances from a single Metadata. >> >> >> Methods of Type needing Session: I used to call them passing null in some >>> old code and hoping for the best. Are the reasons for using Session still >>> present? Would be nice to get rid of that. >>> >> >> This is only ever needed (sometimes) from EntityType. I guess it depends >> which specific method(s) you are asking about. For some (reading, writing) >> yes I think we will continue to need the Session: it is used for access to >> JDBC as well as other needed interactions with the Session/PC (scheduling >> ids for batch load, etc). For other methods, maybe not. >> >> >> On the genericization of Type, it would be extremely nice indeed for OGM, >>> but it would require to genericize SqlTypeDescriptor and its methods >>> essentially. Not necessarily super trivial. >>> >> >> I understand that. It is not a primary goal for me tbh. But if we can >> get a decent design for the ORM case and can see an easy way to extend this >> to OGM without negatively impacting ORM I am all for it. Given the >> delegation to Binder and Extractor I think this will be doable, although I >> assume we will need some parameterized param object to make this work. The >> paam object would give us access to "JDBC services" in ORM and something >> else in OGM. >> >> >>

The contextualization would only work when user calls metamodel.entity(). Not the other methods > On 22 juil. 2016, at 11:14, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; 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. > > 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. > > An alternative that I can think of is as follows. I'm assuming that the > data that needs to be contextualized by the path is mapping in nature or > at least not at all represented in the JPA types. > Each (JPA) type instance would be inherently specific to the path it > comes from. It would keep exposing the JPA non contextualized info but > also add contextualized info. > > HibernateEntityType<Foo> fooModel = > (HibernateEntityType<Foo>) entityManagerFactory.getMetamodel().entity(Foo.class); // considered a root for navigation > > for (HibernateSingularAttribute sa : fooModel.getSingularAttributes()) { > if (sa.getPersistentAttributeType() == EMBEDDED) { > HibernateEmbeddableType et = (HibernateEmbeddableType) sa.getType(); > for (HibernateSingularAttribute esa : fooModel.getSingularAttributes()) { > if (esa.getPersistentAttributeType() == BASIC) { > int span = esa.getPhysicalInfo().getColumnSpan(); > } > } > } > } > > Hopefully, JPA does not mandate == between different types. > > A question I have is how navigable and easy such API would be for a > persister. But that's something to explore. > > Emmanuel > >> On Thu 2016-07-21 21:10, Steve Ebersole wrote: >> Put another way, I think the problem (and probably the solution) here is >> similar to JPA's Bindable (and Path) concept. >> >>> On Thu, Jul 21, 2016 at 2:27 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: >>> >>> One goal of the redesign is to build more friendly, easy-to-follow >>> contract for access to this metadata at runtime (legacy persister state). >>> Rather than accessing pieces of information pertaining to attributes across >>> many, many arrays I wanted an array of a composite representation of these >>> attributes. JPA defines it this way, so on some level you'd think it would >>> be pretty straightforward to move this direction. The major pain-point I >>> have been facing is that JPA does not define "mapping information" at all >>> in its Metamodel/Types. The main place this comes to a head is >>> EmbeddableType, especially given access to it directly on Metamodel *by >>> class*. In JPA terms that return has to model the Embeddable (no mapping >>> info) rather than the Embedded. And then further when we >>> expose EmbeddableType's attributes we have the same problem continued >>> because the context/root is the embeddable rather than the embedded. >>> Hopefully this makes sense, but as an example consider (using a "component >>> safe NamingStrategy): >>> >>> @Entity >>> class Store { >>> ... >>> @Embedded >>> Address headquartersAddress; >>> @Embedded >>> Address locationAddress; >>> } >>> >>> @Embeddable >>> class Address { >>> String streetAddress; >>> @Embedded >>> PostalCode postalCode; >>> ... >>> } >>> >>> @Embeddable >>> class PostalCode { >>> String zip; >>> String plus4; >>> @ManyToOne >>> City city; >>> } >>> >>> Then consider that JPA frames access to this information as: >>> >>> EmbeddableType<Address> addrType = metamodel.embeddable( Address.class ); >>> >>> Because it is generic to the Address embeddable, we have no access to the >>> specific embedded mapping info. And if we follow this access down further, >>> it also means the same for accessing the attributes of that EmbeddableType<Address>. >>> For example, accessing the "postalCode.zip" from the EmbeddableType<Address> >>> we'd have no ability to resolve whether that maps to "headquartersAddress_postalCode_zip" >>> or "locationAddress_postalCode_zip". And of course, as an ORM we need >>> access to that mapping information :) >>> >>> Essentially that is the crux of the difficulty I have at the moment. >>> >>> I know we could get around this by splitting (or keeping split) the >>> notions of ORM Type and JPA Type, but I would like to avoid that : this >>> unification is going to be important to the SQM Criteria support. >>> >>> So the question becomes how to best handle exposing an "Attribute" with >>> mapping information as well as an "Attribute" without mapping information. >>> >>> I will be working on some proposals for ways to do this over the next week >>> or so. And maybe y'all see a solution easier than I do (I fear I may not >>> be seeing the forest through the trees atm). >>> >>> >>> On Thu, Jul 21, 2016 at 7:49 AM Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> I am working on a larger response to some current challenges, but here is >>>> a quick response to your specific points... >>>> >>>> On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard < emmanuel(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> >>>>> BasicType does not handle multiple column and compositeType is the >>>>> mebedded case. How would multi-column types would be handled? >>>> >>>> In terms of what exactly? Assuming you mean access to the JDBC >>>> descriptors, that is still being determined. At the moment there is no >>>> single Type-level access to this information. Each specific Type >>>> sub-interface defines access differently. I am not a fan of that that >>>> aspect. The other approach is to define a plural form on Type >>>> (Type#getColumnMappings), and BasicType would just ensure that there is >>>> just one. >>>> >>>> >>>> Why do you need to ”unscope" the TypeConfiguration? What do you gain from >>>>> it? I’m trying to picture a reuse use case? >>>> >>>> Functionally we do not gain anything. I was just trying to be balanced. >>>> We injected the SF into the TypeConfiguration, I wanted to un-inject it as >>>> well for 2 reasons: >>>> >>>> 1. release the reference to the SF >>>> 2. prepare the TypeConfiguration for binding to another SF. >>>> >>>> The only use case I had in mind was tests where we occasionally build >>>> multiple SF instances from a single Metadata. >>>> >>>> >>>> Methods of Type needing Session: I used to call them passing null in some >>>>> old code and hoping for the best. Are the reasons for using Session still >>>>> present? Would be nice to get rid of that. >>>> >>>> This is only ever needed (sometimes) from EntityType. I guess it depends >>>> which specific method(s) you are asking about. For some (reading, writing) >>>> yes I think we will continue to need the Session: it is used for access to >>>> JDBC as well as other needed interactions with the Session/PC (scheduling >>>> ids for batch load, etc). For other methods, maybe not. >>>> >>>> >>>> On the genericization of Type, it would be extremely nice indeed for OGM, >>>>> but it would require to genericize SqlTypeDescriptor and its methods >>>>> essentially. Not necessarily super trivial. >>>> >>>> I understand that. It is not a primary goal for me tbh. But if we can >>>> get a decent design for the ORM case and can see an easy way to extend this >>>> to OGM without negatively impacting ORM I am all for it. Given the >>>> delegation to Binder and Extractor I think this will be doable, although I >>>> assume we will need some parameterized param object to make this work. The >>>> paam object would give us access to "JDBC services" in ORM and something >>>> else in OGM. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org&gt; 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.

data that needs to be contextualized by the path is mapping in nature or at least not at all represented in the JPA types. Each (JPA) type instance would be inherently specific to the path it comes from. It would keep exposing the JPA non contextualized info but also add contextualized info. HibernateEntityType<Foo> fooModel = (HibernateEntityType<Foo>) entityManagerFactory.getMetamodel().entity(Foo.class); // considered a root for navigation for (HibernateSingularAttribute sa : fooModel.getSingularAttributes()) { if (sa.getPersistentAttributeType() == EMBEDDED) { HibernateEmbeddableType et = (HibernateEmbeddableType) sa.getType(); for (HibernateSingularAttribute esa : fooModel.getSingularAttributes()) { if (esa.getPersistentAttributeType() == BASIC) { int span = esa.getPhysicalInfo().getColumnSpan(); } } } }