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 [EMAIL PROTECTED] 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 <[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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
