Re: proposal for CallableStatements to handle multiple out

Dave Cramer wrote:
> I'd like to move all of that stuff into it's own class, as the rest of
> my patch ends up with alot of if( instanceof CallableStatement) which
> I'd like to avoid by putting it all in a CallableStatement
> implementation.

If I understand what you're suggesting, you want to do this:

AbstractJdbc1Statement
-> Jdbc1Statement extends AbstractJdbc1Statement
-> AbstractJdbc1CallableStatement extends AbstractJdbc1Statement
-> Jdbc1CallableStatement extends AbstractJdbc1CallableStatement
-> AbstractJdbc2Statement extends AbstractJdbc1Statement

The problem is then that you can't reasonably implement
AbstractJdbc2CallableStatement: it needs to extend both
AbstractJdbc2Statement (to get the extra JDBC2 Statement methods) and
AbstractJdbc1CallableStatement (to get the CallableStatement
functionality) simultaneously, and Java doesn't let you do mixins or
multiple inheritance..

A strategy-object approach would work, though. I'm not sure if it would
be much of a win over the current approach though -- you still need all
the CallableStatement methods in AbstractJdbc1Statement, they just turn
into hooks that call the strategy object's implementation.

Have you looked at my patch? It localizes most of the conditionalization
of the CallableStatement case into one place (there is an
adjustParameterIndex() method that does the index translation; it's an
identity transform if the statement isn't a CallableStatement).

I'd also prefer an explicit field on the statement to say "this
statement is callable!" rather than relying on instanceof, it always
struck me as too fragile to rely on exactly which classes the concrete
JdbcN classes implement.

-O