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