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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev