commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: Re: [DBUtils][patch] executeQuery method
Date Sat, 23 Nov 2002 19:25:48 GMT

I'm not sure it's sounding crossdb like, it just doesn't scope to
large sets of data. I'm suggesting we have:

ResultSet executeQuery(PreparedStatement ps, Object[], int[])
and
Iterator executeQuery(String sql, Object[], int[])

where the latter uses the former. But is javadoc enough to specify when a
method doesn't scope?

Hen

On Sat, 23 Nov 2002 travis@thinkvirtual.com wrote:

> I haven't been following this thread, but this is sounding very
> crossdb like?
>
> In any case, after reading this message, executeQuery should
> definitely return a ResultSet, not an iterator as Ken said.  That is
> ridiculous even thinking to return an iterator and pulling the whole
> resultset into memory.  Would be almost unusable in any large data
> situation.
>
> Travis
>
> ---- Original Message ----
> From: Henri Yandell <bayard@generationjava.com>
> Sent: 2002-11-22
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: [DBUtils][patch] executeQuery method
>
>
>
> On Fri, 22 Nov 2002, Ken Horn wrote:
>
> >
> > Personally this executeQuery call is almost identical to ones I write
> > everywhere I go... I don't think the executeQuery, should return any
> > type of Iterator, but the ResultSet itself. This avoids the whole memory
> > issue for large result sets. If you're passing a Connection you're not
> > really hiding jdbc use anyway.
> >
> > I normally make the interface:
> > ResultSet executeQuery(Connnection c, String sql, List params);
> > ResultSet executeQuery(Connnection c, String sql, List params, int[] types);
>
> Does this work? Does JDBC say that you can close a Statement and the
> ResultSet will not close and still be usable? That's the reason for not
> returning ResultSet. It seems there are two options, where
> resource-management is either fully hidden, or not hidden at all:
>
> 1)   ResultSet executeQuery(Connection, PreparedStatement, <params>)
> 2)   <memory> executeQuery(Connection, String, <params>)
>
> Where <memory> is Iterator/List/Object[], and <params> is
> Object[]/List/Iterator.
>
> I'm actually happy to offer both versions. The current one would reuse
> this one.
>
> > with versions for update and also allowing to pass a PreparedStatement
> > in too (incase it needs special preparation). The types int[] is so you
> > can correctly set NULL values with a null reference, on certain drivers
> > (Sybase and (i think) Oracle).
>
> The int[] is a good thing. It's ugly, but the only real way around the
> null irritation as knowing which type = which column is db dependent and
> sql-statement dependant. [wtf is it with Oracle always returning
> BigDecimal :)]
>
> > If your looking to wrap the returned fields into a grid style object,
> > then do so
>
> This goes against the concept of DbUtils I think. It's not meant to invent
> a new API to hide JDBC, but to only use the existing stuff in JDK. Else it
> becomes a pointless component, there are lots of higher level JDBC hiding
> things out there. Commons.sql does this for one I think.
>
> I imagine this will be a broken record on DbUtils. It is definitely a
> project with a limit on its scope. It must be db-independent, and it
> mustn't force people to adopt a new religion [framework]. My view anyway
> :)
>
> Hen
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message