Oliver,
It is more of a Strategy object. As you pointed out I have to use a
strategy object.
I'm not interested in "winning"; I'm more interested in implementing
this in such a way as to not muck up the current code, and add
CallableStatement functionality in such a way that if, in the future
postgres supports multiple out parms, it will be easy to change.
Dave
On Sun, 2004-06-20 at 10:17, Oliver Jowett wrote:
> Dave Cramer wrote:
> > 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.
>
> So essentially the SqlParser is a strategy object, or maybe strategy +
> some state? Which object holds what state?
>
> -O
>
>
>
> !DSPAM:40d59c25234101391917376!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561