On Wed, Oct 19, 2016 at 2:29 PM Jordan Gigov <coladict(a)gmail.com&gt; wrote: I've been reading the wiki and email archives, and I have some notes for what needs to be decided before it needs to become retrofitted. After all, all that retrofitting is what the reason the types need to be redesigned. LiteralType.objectToSQLString is only used to append the DiscriminatorValue. Can't it just work with regular binding to the PreparedStatement so the unsafe interface can be removed? LiteralType will not be part of the new contracts. A type should be able to define classes Interfaces and Abstract classes that it can handle in their Java types. This will enable implementing handlers for things like javax.script.* objects that can have different providers, thus different class names of the final object. That would have to be a secondary check if no match is found by Java class name, because it's slower and dangerous when binding parameters to a query. I am not sure what you are talking about here. If stored as Class object references, they would have to be held in WeakReference objects tied to a ReferenceQueue, so as not to prevent garbage collection when a context is unloaded in a multi-context server. If stored as Strings, there would have to be a call to Class.forName for each, which if successful would have to check isInstance on the object or isAssignableFrom on it's class (when evaluating DB model). Again, not really sure what you are talking about here. I guess you mean in some "cache" based on the Java type handled? And, generally speaking Hibernate never requires Java types for its type system because Hibernate supports detyped domain models; the one outlier there is any type deemed to be "basic" - those do require Java type. There are currently no notes on how to handle binding the values to a PreparedStatement/CallableStatement. https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign#read-... We just have not gotten to that point yet where that is better defined. There is also no mention of how java.sql.SQLType that was added in Java 8 comes into play, which will help with vendor-specific types. There is currently not any plan to support java.sql.SQLType When converting the new types to a bindable object they will need access to the Dialect and these methods of the java.sql.Connection: createArrayOf createBlob createClob createNClob createSQLXML createStruct getClientInfo getMetaData which returns DatabaseMetaData which can give access to the java.sql.Connection if we're trying to abstract away from it. Statement also gives you access to the Connection (Statement#getConnection) Maybe also to: setClientInfo getWarnings when reading results from the database getTypeMap setTypeMap Reading the description of javax.persistence.metamodel.Type, I'm not sure it serves the same purpose as Hibernate's Type and that it should be a super-interface of it. In fact, starting to read the Metamodel API chapter where these interfaces are defined, I'm fairly certain it's supposed to reflect the structure of the persistence unit. In other words, I don't think javax.persistence.metamodel.Type fits anywhere in this picture and it's a different concept altogether. As has been discussed elsewhere, that is correct. JPA's metamodel actually only describes the Java domain model. There is no database nor mapping information associated with it. JPA's type system is actually closer to Hibernate's JavaTypeDescriptor contract; not so much Hibernate's Type contract. Chris and Andrea are working on a prototype to see about having JavaTypeDescriptor implement the JPA type contracts. As for OGM (which I've never used, but here's an idea) the problem with SqlTypeDescriptor (discussed in end of June, as I read the mail archives) maybe could be turned into an extension of a more generic StorageTypeDescriptor, and SQL would be just one type of storage? I don't know how that would work, since I've never had to use NoSQL and don't even know if that makes sense. Maybe the persistence context should provide the binders/extractors to each type upon use. That wont work, because you'd also have to abstract the "database access". Anyway the only place I am concerned about that is in SQM and the type information it needs. I have already developed a proposed contract on the SQM side which I have already prototyped for ORM usage and is being evaluated for its appropriateness for OGM. So we shall see soon on that front. As far as the "mapping Type", I do not see a nice solution for ORM and OGM to share that I want to take on at this point. As I said above it would also mean abstracting access to the underlying data store (NoSQL and object stores do not exposed JDBC Connections, or if they do that is usually not the preferred/performant way to access them). This discussion is (waaaaaay) beyond the scope of this work. In general a lot of points are just out of date. If you want to influence the development of this or be part of it you should consider joining the HipChat channel where we discuss this stuff. I stopped trying to discuss here because no one generally answers.