Abstraction from JDBC is not my primary concern atm tbh. I think
ValueExtractor/ValueBinder
*could* be made to work in a way that is datastore agnostic (not JDBC
dependent).
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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>