[hibernate-dev] 6.0 - Type redesign

[Gunnar Morling]

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
>>>>
>>>
>>>