[hibernate-dev] 6.0 - Type redesign

Steve Ebersole steve at hibernate.org
Tue Jun 28 11:38:15 EDT 2016

Abstraction from JDBC is not my primary concern atm tbh.  I think
*could* be made to work in a way that is datastore agnostic (not JDBC

Like I said, I am not a fan of `int[] Type#sqlTypes`.  I think that ought
to be `SqlTypeDescriptor[] Type#getSqlTypeDescriptors`

Aside from SqlTypeDescriptor#getSqlType, SqlTypeDescriptor is not meant to
be SQL/JDBC-specific.  And even #getSqlType is really just meant as a
"key", a way to easily identify a particular SqlTypeDescriptor.

On Tue, Jun 28, 2016 at 9:37 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Steve,
> Yes, assuming ValueExtractor/ValueBinder are going to be sufficiently
> generified (i.e. no usage of java.sql.* types such as ResultSet,
> PreparedStatement etc. in the method signatures), it might fly for OGM, too.
> No idea though how feasible that'd be. Once you have some sort of PoC, we
> should try it out very quickly with OGM (i.e. implement the new contracts
> for a handful of types) so to see whether that's the right path or not.
> Having one generic facade for SQL and OGM's needs would be great. But it
> might be asking too much, I am really not sure.
> Some more thoughts on the wiki (great write-up btw., that's much
> appreciated):
> * Type#sqlTypes() would be an issue for OGM
> * BasicType#getSqlTypeDescriptor(), too; Or would you expect us to provide
> a NoSqlBasicTypeDescriptor contract here? I.e. is BasicType meant as a
> generic contract across SQL/NoSQL backends or just specific for SQL?
> * I like the proposal of not passing in Mapping to getColumnMapping() et
> al.
> --Gunnar
> 2016-06-28 15:24 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> Ok, I need to move forward on this and I have gotten enough affirmative
>> feedback to ahead.
>> On Fri, Jun 24, 2016 at 6:24 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>> This is all part of the to-be-decided read/write part of the new Type
>>> contract.  I propose, as discussed in the wiki, that we have Type return
>>> ValueExtractor and ValueBinder for read/write.  So assuming that is there...
>>> One possible answer to your story is that OGM as a SQM interpreter and
>>> Metamodel (persisters, etc) implementor would influence the Type and
>>> therefore the ValueExtractor and ValueBinder.  We'd just need to define the
>>> right generic API to allow that to happen without ORM, e.g., having to jump
>>> through a bunch of hoops to get to JDBC objects.
>>> On Fri, Jun 24, 2016 at 5:18 PM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>> Steve,
>>>> I still need to look at the wiki page and will give more detailed
>>>> feedback on some parts of it.
>>>> One general thing coming to mind though is how support for OGM could be
>>>> improved. On first thought I'd say the "Java side" of Type might stay as
>>>> is, but the "SQL side" (or "datastore side") and read/write logic
>>>> interacting with result sets etc. would have to look differently in the
>>>> case of OGM.
>>>> If this part of the story could be made pluggable somehow, than a
>>>> custom factory of sorts in OGM could plug in its dedicated implementation
>>>> of the "datastore side". Not sure how it'd look in practice, the
>>>> implementations would be rather different (we don't work with ResultSet at
>>>> all in OGM), so I suppose it might require casting to the expected subtype
>>>> when working with Type in ORM or OGM.
>>>> Currently, we completely override the Type hierarchy from ORM with a
>>>> corresponding GridType hierarchy in OGM, but it might be possible to re-use
>>>> many more code by just customizing the "datastore side". Plus, it'd be a
>>>> tad more efficient for OGM, as we can skip the translation from Type to
>>>> GridType.
>>>> I might provide some more details once having studied the current
>>>> proposal in more depth, just wanted to get out these thoughts to you.
>>>> --Gunnar
>>>> 2016-06-22 18:54 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>>>> I started a wiki discussing the proposal for the type system redesign.
>>>>> Let's get discussions about it starter sooner rather than later.
>>>>> Thanks!
>>>>> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

More information about the hibernate-dev mailing list