Re: [hibernate-dev] 6.0 - Type system

trying to find a valid reason to keep UserType but not able, so I'm for removing it. On 23 January 2017 at 14:36, Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: > Hi, > > I see no reason why we should keep it indefinitely. I'd say we deprecate it > in 5.x, and remove it later (6.0 or 6.1). > Migrating a custom UserType to using Java and SQL descriptor is not > difficult, and we could just write a blog post for a step-by-step guide. > > Anyone in favor of keeping UserType? > > Vlad > > On Mon, Jan 23, 2017 at 4:11 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Nice! >> >> So if we keep UserType, we have to be clear that it has to change. I > also >> do not want to continue to support the other "user type extensions", > like: >> >> 1. org.hibernate.usertype.EnhancedUserType >> 2. org.hibernate.usertype.DynamicParameterizedType >> 3. org.hibernate.usertype.LoggableUserType >> 4. etc >> >> So we should come up with a plan for that. >> >> >> On Mon, Jan 23, 2017, 1:48 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; >> wrote: >> >> Hi, >> >> I like the SqlTypeDescriptor and JavaTypeDescriptor much better than >> UserType, which we should probably deprecate in 6.0. >> >> I wrote an article on my blog in which I demonstrate how to create a JSON >> type using JavaTypeDescriptor and SqlTypeDescriptor: >> >> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects- >> using-generic-hibernate-types/ >> >> I like this example because it shows how you can reuse the same >> JavaTypeDescriptor for two different JSON SQL types: String or Binary, >> for which we have two distinct SqlTypeDescriptor objects. >> >> The new User Guide shows ho to implement Custom Types using the Java and >> SQL descriptors as well: >> >> http://docs.jboss.org/hibernate/orm/5.2/userguide/ >> html_single/Hibernate_User_Guide.html#basic-custom-type >> >> Vlad >> >> On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >> Right, and that exactly lines up with what I am proposing. >> >> If the intent of "customize" is to describe new Java types (e.g. Java 8 >> temporals prior to our explicit support) the tht is the role of a >> JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would >> register a BasicJavaDescriptor describing the type. >> >> If the intent is to model a non-supported SQL type then that would mean >> adding a new SqlTypeDescriptor describing that type, although that will >> often also mean adding a new BasicJavaDescriptor describing the Java >> mapping of that SQL type. >> >> >> On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; >> wrote: >> >> Hi, >> >> Related to your questions: >> >> he main thing I wonder about is what we mean by "custom >> types" in terms of what exactly is being customized? And how does that >> relate specifically to BasicType versus EmbeddedType versus ...? >> >> >> Most of the time, the users want to take advantage of various database >> types that are not universally supported by all RDBMS: JSON, Money (SQL >> Server). >> >> On the Java side, I don't see what we can customize because we already >> provide all the basic types, and for everything else, users can compose >> those into Embeddables. The Java 1.8 Date/Time are an example of what > users >> would like to customize in case we didn't support this already. But even > if >> Java 1.9 adds other basic types, chances are that we are going to support >> them natively, meaning that users will still not need to add a custom > Type. >> So, I don't see how a Hibernate user will customize the way Embeddables, >> Enums, Entities or Collections are being stored or loaded from the >> database. The exception to the rule is a recent Pull Request from someone >> who wants to support PostgreSQL arrays. But this falls back into the same >> category as before: database types that are not universally supported by >> all RDBMS. >> >> Vlad >> >> On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; >> wrote: >> >> There's a lot to dig in here. I'll have to get the branch and study the >> changes, to come back with some opinions. >> >> Vlad >> >> On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >> We are getting pretty far along on the 6.0 changes and I wanted to start >> a(nother) discussion about Types in 6.0 to get feedback and thoughts on a >> few topics. >> >> First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, > Types >> and "persisters"... >> >> (a lot of this is the same from pre-6.0, just making things more > explicit) >> JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so > let's >> start there. A JavaTypeDescriptor is a descriptor of a given Java type. >> That is, it provides Hibernate with information about the Java type. Is > it >> a numeric type? How do we compare 2 values of this type? How do we > make a >> deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, >> but for a database type (VARCHAR, BLOB, etc). These 2 work together to >> perform reading and writing at the JDBC-level. >> >> We decided to broadly categorize JavaTypeDescriptors based on the JPA > type >> categorizations: >> >> 1. BASIC - BasicJavaDescriptor >> 1. TemporalJavaDescriptor >> 2. NumericJavaDescriptor >> 2. MANAGED - ManagedJavaDescriptor >> 1. EMBEDDABLE - EmbeddableJavaDescriptor >> 2. IDENTIFIABLE - IdentifiableJavaDescriptor >> 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor >> 2. ENTITY - EntityJavaDescriptor >> >> >> Type (org.hibernate.type.spi.Type) represents a combination of a >> JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a >> specific "non-root Navigable domain value". Navigable is a query-focused >> contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a >> high-level t is similar to JPA's Bindable except that it applies to >> Collection indices (or map-keys) and elements (or map-values) as well. >> Navigable essentially represents an named navigation one can perform in a >> query. The root Navigable is always an entity (EntityPersister). >> EntityPersister is the only Navigable that does not expose a Type. > (There >> is an EntityType, but it represents entity-valued non-root Navigables > such >> as a ManyToOne). All other navigables expose a Type. That is all a >> long-winded way to say that Types represents that Java/SqlTypeDescriptors >> for a role-based Navigable. >> >> Like the categorization discussed above for JavaTypeDescriptor, Type has > a >> similar categorization: >> >> 1. Type >> 1. BasicType >> 1. TemporalType >> 2. AnyType >> 3. ManagedType >> 1. EmbeddedType >> 2. IdentifiableType >> 1. MappedSuperclassType >> 2. EntityType >> >> It is important to keep in mind that these represents a specific > reference >> to thse things in regards to a Navigable. E.g. an EntityType is the > "type" >> of a SingularPersistentAttribute that is a ManyToOne - it points to the >> corresponding EntityPersister but it also represents the FK columns to >> refer to the entity. It is a role-based Navigable. >> >> Historically reads and writes have all routed through the Type (with >> certain Types delegating much of that to persisters). That will no > longer >> be the case in 6.0 as one of the main design goals for 6.0 is to re-write >> how Hibernate reads and writes (mainly reads) values from JDBC. The > major >> shift here is to read all values from JDBC using a "SqlSelectionReader" >> equivalent to a BasicType. These values are read and held in an array > that >> "readers" then know how to access (positionally) and use. Most of that >> design is beyond the discussion here, but it useful to understand. It is >> discussed in the design.adoc in my orm-sqm poc repo for those curious. >> Long story, short... Types no longer directly implement JDBC read/write >> which we will come back to later. >> >> PersistentAttribute and the other Navigables now take a role in JDBC >> reads/writes. AttributeConverters and other read/write-related concerns >> have been moved to these contracts. Again, most of this is covered in > the >> mentioned design doc. >> >> Since Type no longer directly implements JDBC read/write operations I > think >> it is important to ask ourselves what exactly we see as "customizable" > wrt >> each Type. Is that different for each category, or the same across all >> Type categories? E.g. I know of no customization of EntityType as it >> exists in 5.x, and tbh I am not even sure what that would mean. > BasicType >> obviously has some parts that we want to allow users to override, but is >> that really best achieved through a custom BasicType? Or is it better >> served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or >> SqlSelectionReader? What about EmbeddedType? CollectionType? This > would >> affect @TypeDef and Type registration methods specific to customizations. >> >> Persisters for the most part continue to serve the same role they have in >> the past with a few additions and some changes... >> >> One addition was the creation of an EmbeddedPersister. *Embedded*. > This, >> like CollectionPersister, models a "role" e.g. "Person.name" as opposed > to >> the Embeddable Name.class. Note however that JPA calls it an >> EmbeddableType and expects info about the Embeddable (the Class). >> EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. >> In the case there are more than 1 usage of the Embeddable in different >> Embedded roles then we have to decide which EmbeddedPersister to return. >> It affects the sub-Attributes information. We could just return "one of >> them" and deal with it for Alpha1, but we should answer what we want to > do >> there long term. >> >> Collectively, these persisters now implement the JPA ManagedType model >> directly. Another addition was the creation of ManagedTypeImplementor, >> IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the >> persister hierarchy. Which means we can now directly return them in our >> JPA Metamodel impl. >> >> That also means implementing JPA's notion of Attributes. I also needed >> something similar for SQM's Navigable contract. Plus I have been working >> towards changing how Hibernate understands Attributes internally >> (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed >> well. >> >> There are some things we should discuss too in terms of user impact. We >> know up front that we need to move to reading values from JDBC ResultSets >> positionally, as opposed to nominally which is how it was exposed in >> Hibernate prior to 6.0. So we know already we will be asking > implementors >> and consumers of those contracts to make changes. Given that, we have >> *some* liberty in changing these contracts some more. We just want to be >> cognizant of (a) how much we change, (b) who it affects (use cases) and > (c) >> whether there are alternatives. For any use cases we determine to be >> "valid" use cases, I think we need to make certain that there is some way >> to handle that in the new alternatives. >> >> One use case, e.g., is setting Query parameters and being able to specify >> its Type. To a degree we want to be able to continue to support that. > But >> I think we limit it to just references to org.hibernate.type.Type (though >> "gutted") specifically and remove all others; and temporarily have the > new >> org.hibernate.type.spi.Type interface extend the old. This would allow >> them to continue to get these org.hibernate.type.Type references in some >> fashion and use them as Query parameter type hints. But I think we > should >> look at implementing some other parameter type "hints" like accepting >> PersistentAttribute/Navigable references, JPA (static) metamodel >> references, etc. These are better, as they would include things like >> AttributeConverter whereas the Type reference would not. >> >> Sorry this got so long. I've had a lot floating around in my head the > last >> few days as I have worked on 6.0 and I wanted to bring them up for >> discussion. The main thing I wonder about is what we mean by "custom >> types" in terms of what exactly is being customized? And how does that >> relate specifically to BasicType versus EmbeddedType versus ...? >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev