On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote: > > It would be nice to make the return value generic: > > public T accept(PreparedStatementQueryOperation operation, Class<T> > resultClass);
95 times out of 100 inside Hibernate code we really can't take advantage of the parameterized type. So its less important in my mind. Like I said earlier, the intent here is not to build a general purpose JDBC abstraction library. But if you look at Operation you can see it is parameterized (Operation<T>) and that accept() leverages that: public <T> T accept(Operation<T> operation); > > I can see the merit of breaking out > PreparedStatementQueryOperation.getStatementPreparer(), > getStatementExecutor().execute(), and > getResultSetProcessor().extractResults(), as opposed to > PreparedStatementQueryOperation.prepare(), execute(), extractResults(). > > I think there should also be a > PreparedStatementQueryOperation.getStatementBinder() returning a > StatementBinder, since it's really a step that is separate from preparing. Yep, I contemplated the same. > > In the case where operation.holdOpenResources() == true, which object > would hold the open resources? If it's JdbcSession that manages them, > there would also need to be JdbcSession.closeResources( operation ); > otherwise, something like > PreparedStatementQueryOperation.closeResources() would be needed. Its the ResourceRegistry which in the actual code. It does not segment resources by the operation they come from atm. The only thing it x-refs is Statement->ResultSets. I am not sure it is worth the overhead to do this segmenting either. But you are correct, if we did segment these registered resources by operation we would need a level of releasing them by operation too. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
