[hibernate-dev] JdbcSession -> DataStoreSession

[Steve Ebersole]

I'm thinking about just dropping this (the agnostic part) as it is not 
really getting any traction with or looks from the non-ORM folks.

On Mon 16 Dec 2013 07:55:36 AM CST, Emmanuel Bernard wrote:
> In the old (4.2) Persisters / Loaders, the ResultSet API was pretty pervasive
> and passed form methods to methods.
> With the Operation approach, that cannot be the case anymore. But if
> that can be done, that's better for OGM.
>
> Also, that's a bit out of my league, but I wonder if that operation
> design can lead to too much memory pressure due to more objects being
> created. Maybe that's just premature optimization at this stage.
>
> Emmanuel
>
> On Mon 2013-12-16  7:24, Steve Ebersole wrote:
>> The Operations are store specific.  So there would be a specific Operation
>> for performing a JDBC query and either extracting the results (normal use)
>> or accessing the ResultSet (ScrollableResults use).   There would be some
>> other Operation impl(s) for doing the same against no-sql stores.  Operation
>> is really meant to be model an end-to-end interaction with the backing
>> store.
>>
>> The thing that "clicked" for me was realizing that even though each back-end
>> would need varying Operation impls almost all of these usages come from
>> persisters and loaders which OGM already provides alternatives for.  We'd
>> just replace them (persisters/loaders and DataStoreSession types) in tandem.
>>
>> Keep in mind that the idea here is simply to centralize the binding of
>> connection+transaction in various transaction scenarios and encapsulate
>> handling of "flow" between them.
>>
>>
>>
>> On Mon 16 Dec 2013 01:38:22 AM CST, Emmanuel Bernard wrote:
>>> When I reviewed your work earlier last week, I had the feeling that we
>>> would need to replace JdbcSession with something totally different. OGM
>>> Loader / Persisters would then use that different contract.
>>>
>>> The idea of a generic DataStoreSession is attractive.
>>>
>>> But something I am not clear on is how the generic parameter of
>>> Operation will be used. How can a Loader or Persister invoking
>>> DataStoreSession.accept() retrieves the results? Will it be ResultSet or
>>> some agnostic container too?
>>>
>>> Emmanuel
>>>
>>> On Sat 2013-12-14 11:53, Steve Ebersole wrote:
>>>> As Gail and I discussed the actual API to use in this JdbcSession
>>>> redesign we both liked the idea of sending Operations in to the
>>>> JdbcSession rather than JdbcSession exposing a very granular, JDBC-like
>>>> API.  This got me to thinking that JdbcSession really could be a generic
>>>> representation of a connection+transaction context for *any* back end,
>>>> whether that back-end was JDBC or not.
>>>>
>>>> I discussed this idea a bit with Sanne on IRC.  He was on board in the
>>>> general sense.
>>>>
>>>> So this morning I spent some time re-working the code to express this
>>>> concept.  I just pushed this out to my repo.  The main contract now is
>>>> org.hibernate.resource.store.DataStoreSession.  The JDBC realization of
>>>> this contract is defined by
>>>> org.hibernate.resource.store.jdbc.JdbcSession (which extends the
>>>> DataStoreSession).
>>>>
>>>> The nice thing is that this all ties in seamlessly with the
>>>> TransactionCoordinator.  There is a notion of "resource local
>>>> transactions" and "jta transactions".  "resource local transactions"
>>>> ultimately come from the DataStoreSession which allows integrating
>>>> back-end specific notions of transactions by implementing a
>>>> org.hibernate.resource.transaction.ResourceLocalTransaction for that
>>>> back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction
>>>> for example for JDBC).
>>>>
>>>> Anyway, it was a nice exercise even if y'all decide to not use this in
>>>> OGM.  It forced me to think about the separation between the 2 main
>>>> packages (org.hibernate.resource.transaction versus
>>>> org.hibernate.resource.store) and to remove the cyclic deps.
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev