It is more of a Strategy object. As you pointed out I have to use a
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.
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?
519 939 0336
ICQ # 14675561
In response to
pgsql-jdbc by date
|Next:||From: Laurent Sylvain||Date: 2004-06-21 13:00:09|
|Subject: Bug (and fix): leaks of TCP connections when connected to a <7.4 server|
|Previous:||From: Sreenivas Ganji||Date: 2004-06-21 07:22:44|