[hibernate-dev] JdbcSession proposal

[Steve Ebersole]

See inline...

P.S. Latest revs pushed to my upstream repo


On 01/06/2014 02:48 PM, Brett Meyer wrote:
> * +1 for the "Operation API", over the granular set of boilerplate code.  Also, imo, I'd overload the API methods with the specific Operation impl arguments (ex: #accept(PreparedStatementQueryOperation)), rather than only one (ex: #accept(Operation)).  I tend to think it's cleaner, removing type checks, etc.  I know there was already some debate about that, so just my $.02.

Operation is a "free flow" contract much like Work.  Not sure what kind 
of "concrete impls" you see.  Maybe you are thinking of the 
OperationSpec concept...

But even for OperationSpec I am not sure overloading the methods is a 
good idea.  I generally consider exploding an API 1+1 for new types is 
an anti-pattern.  Let's just let the API evolve as we move further in 
the design and not force stuff up front...

> * If you haven't already, define default Operation impls and use wherever possible?
Again, I think you are thinking of OperationSpec...

> * There was some discussion comparing the difficulty of integrating each possibility into ORM.  Imo, *any* of them will be difficult.  Removing the proxy system was a gigantic, tedious pain.  That being said, let's make sure we identify all possible future needs, including the applicability of DataStoreSession, and do them once.  I'd hate to roll with something, then have to change/extend it later on.  The proposal process has already been doing this, but it's worth mentioning.
Not sure this is accurate.  The "low-level API" is much closer to JDBC 
and would be much easier to swap in than the Operation-style 
approaches.  Trivial?  No, just much easier.

As far as DataStoreSession, I've already reverted that work.  There was 
no interest from those who it would have benefitted and it just muddied 
the waters for straight JDBC usage.  And I whole-heartedly agree that I 
consider this as "that ship has sailed"; meaning I will not be going 
back and changing JdbcSession to an agnostic DataStoreSession down the 
road.  While it would have been nice to do up-front, it would be just 
too much work to add on later.

> * Relying on the JTA Synchronization makes sense conceptually, but have we received any feedback from JBossTS?

> * Regarding the above, +1 for (conceptually) not caring about Synchronization failing for rollback-only and failing fast.  But, just want to make sure we're not overlooking something.
Yep.  I have discussed with Tom a few times.  Scott and I are doing one 
last round of discussion with him just to re-re-re-confirm.

> * How would CMT fit into this?
Don't understand the question.