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 <[EMAIL PROTECTED]> Sent: 2002-11-22 To: Jakarta Commons Developers List <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
