On Wed, Oct 19, 2016 at 2:29 PM Jordan Gigov <coladict(a)gmail.com> wrote:
I've been reading the wiki and email archives, and I have some
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
LiteralType.objectToSQLString is only used to append the
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
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
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:
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:
getWarnings when reading results from the database
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
maybe could be turned into an extension of a more generic
StorageTypeDescriptor, and SQL would be just one type of storage? I
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
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.