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 <gun...@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 <st...@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 <st...@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 <gun...@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 <st...@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@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>>> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
