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]>
