[hibernate-dev] 6.0 - Type redesign

[Steve Ebersole]

On Wed, Oct 19, 2016 at 2:29 PM Jordan Gigov <coladict at gmail.com> 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-and-write-capabilities

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.