commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: Re: [DBUtils][patch] executeQuery method
Date Sat, 23 Nov 2002 19:28:55 GMT

Which launches us into the beginnnigs of a religion/framework and away
from simply JDBC, but not that much. It seems like a good idea [Connection
needs pulling out, no pool], and we could then have an MemoryIterator
which pulls all the values into memory and other implementations.

Hen

On Sat, 23 Nov 2002, Juozas Baliuka wrote:

>
> It is very trival way to handle JDBC stuff:
>
> interface ResultSetHandler{
>
>   void handle( java.sql.ResultSet rs );
>
> }
> //executes single query
> public void executeQuery( String sql, Object params[],   ResultSetHandler
> handler )throws SQLException{
>  Connection connection =  pool.getConnection();
>  Statement   statement   = null;
>  ResultSet rs = null;
>  try{
>
>     statement   =   connection.prepareStatement(sql);
>
>    for(  int i =0; i< params.length; i++){
>        if(params[i] == null ){
>          statement.setNull( i + 1, Types.OTHER  );
>     }else{
>         statement.setObject( i + 1, params[i], Types.OTHER );
>      }
>
>    }
>    rs = statement.executeQuery();
>    handler.handle(rs);
>
>  }finally{
>
>    close(rs);
>    close(statement);
>    close(connection);
>
>  }
> }
>
>
> This can be modified to support updates and transactions.
>
>
>
>
>
> ----- Original Message -----
> From: <travis@thinkvirtual.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Saturday, November 23, 2002 12:47 PM
> Subject: RE: Re: [DBUtils][patch] executeQuery method
>
>
> > 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>
> >
> >
>
>
> --
> 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