types" in terms of what exactly is being customized? And how does that relate specifically to BasicType versus EmbeddedType versus ...?

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 >

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

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

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

What is everyone's opinion of the following sections? <snip> 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. </snip> On Mon, Jan 23, 2017 at 11:13 AM Christian Beikov <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote: Since custom JavaTypeDescriptors and SqlTypeDescriptors can be used instead, I'm also for removing it. Am 23.01.2017 um 15:45 schrieb andrea boriero: > 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 <mailto:mihalcea.vlad@gmail.com>> 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 <mailto:steve@hibernate.org>> >> 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 <mailto:mihalcea.vlad@gmail.com>> >>> 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 <mailto:steve@hibernate.org>> >>> 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 <mailto:mihalcea.vlad@gmail.com>> >>> 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 <mailto:mihalcea.vlad@gmail.com>> >>> 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 <mailto:steve@hibernate.org>> >>> 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 <mailto:hibernate-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >>> >>> >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev