commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [DBUtils][patch] executeQuery method
Date Fri, 22 Nov 2002 17:25:00 GMT


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>


Mime
View raw message