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