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