No,
What I was planning on doing is encapsulating all the code that parses
the sql, and rewrites it into a small class, StatementSqlParser
implement SqlParser, then changing the contstructor for
AbstractJdbc1Statment to
AbstractJdbc1Statement( Connection, SqlParser )
Then I could create a second class CallableSqlParser which would deal
with the differences in CallableStatements.
Dave
On Fri, 2004-06-18 at 21:00, Oliver Jowett wrote:
> 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
>
>
>
> !DSPAM:40d38fcd300218619219928!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561
