[hibernate-dev] 6.0 - Type redesign

[Jordan Gigov]

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.