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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
