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