commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tra...@thinkvirtual.com
Subject RE: Re: [DBUtils][patch] executeQuery method
Date Sat, 23 Nov 2002 11:47:21 GMT
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>


Mime
View raw message