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? 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. 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). There are currently no notes on how to handle binding the values to a PreparedStatement/CallableStatement. 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. 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. Maybe also to: setClientInfo getWarnings when reading results from the database getTypeMap setTypeMap On Thu Jul 21 15:27:49 EDT 2016 Steve Ebersole <steve at hibernate.org> wrote: > 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. 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 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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
