You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by george stewart <gs...@us-south.net> on 2003/02/21 15:52:57 UTC
[dbutils] public access to ResultSetHandler
Hi,
Could the developers elaborate on reasons for having package access to the interface ResultSetHandler?
If this was public, user's could create objects without using the object arrays.
If it ever becomes public, it would be nice to have something like this in the package:
static void executeQuery(Connection connection, String query,
Object[] vals, ResultSetHandler rsh,
Collection cln
) throws SQLException
{
PreparedStatement stmt = null;
ResultSet rs = null;
try {
stmt = connection.prepareStatement(query);
fillStatement(stmt, vals);
try{
rs = stmt.executeQuery();
while (rs.next()) {
cln.add(rsh.handle(rs));
}
}catch(SQLException sqle){
String msg = sqle.getMessage() + " in query " + query +
java.util.Arrays.asList(vals).toString();
SQLException e = new SQLException(msg);
e.setNextException(sqle);
throw e;
}
} finally {
closeQuietly(rs);
closeQuietly(stmt);
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [dbutils] public access to ResultSetHandler
Posted by Juozas Baliuka <ba...@centras.lt>.
It is not good idea to use dbutils at this time, forke source code if you
need something like this and can not to wait.
I always do this with sandbox components and have no problems to use and
integrate them later.
> "Juozas Baliuka" <ba...@centras.lt> writes:
>
> > It will be public if we will not find better ways to handle resultsets.
>
> Thanks very much for your answer. I'll be watching your changes. Making
some interface public and the ability to fill collections would handle 95%
of our work.
>
> I've been looking for a package like this for some time.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [dbutils] public access to ResultSetHandler
Posted by george stewart <gs...@us-south.net>.
"Juozas Baliuka" <ba...@centras.lt> writes:
> It will be public if we will not find better ways to handle resultsets.
Thanks very much for your answer. I'll be watching your changes. Making some interface public and the ability to fill collections would handle 95% of our work.
I've been looking for a package like this for some time.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [dbutils] public access to ResultSetHandler
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
It will be public if we will not find better ways to handle resultsets.
I am not sure about "connection" parameter too,
connection can be stored in ThreadLoacal, but this will add more "public
API" to component.
It is possible to live without "cln" parameter, handler can be implemented
this way :
class MyHandler implemente ResultSetHandler{
Collection collection;
MyHandler(Collection collection){
this.collection = collection;
}
public boolean handle( ResultSet rs ){
collection.add(rs.getObject(1));
return true;
}
}
static final ThreadLoacal CURRENT_CONNECTION = new ThreadLoacal();
static void executeQuery(String query,Object[] vals, ResultSetHandler
rsh ) throws RuntimeSQLException
// SQLException has no info and it is no ways to handle it in
user code, SQLSTATE ?
{
Connection connection = (Connection)CURRENT_CONNECTION.get();
if( connection == null ){
connection = ConnectionFactory.getConnection(); //pluggable
connection pool implementation
CURRENT_CONNECTION.set(connection);
}
PreparedStatement stmt = null;
> ResultSet rs = null;
>
> try {
>
> stmt = connection.prepareStatement(query);
> fillStatement(stmt, vals);
>
> try{
> rs = stmt.executeQuery();
> while (rs.next()) {
if( !rsh.handle(rs) ){
break;//break if handler doe's not want more
results
}
> }
>
> }catch(SQLException sqle){
> String msg = sqle.getMessage() + " in query " + query +
> java.util.Arrays.asList(vals).toString();
> SQLException e = new SQLException(msg);
> e.setNextException(sqle);
> throw e;
> }
>
> } finally {
> closeQuietly(rs);
> closeQuietly(stmt);
> }
>
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [dbutils] public access to ResultSetHandler
Posted by Juozas Baliuka <ba...@centras.lt>.
Ok, It can be public.
Idea to "hidde" connection in static method is not very good. It is better
to implement some class with instance methods
and "ConnectionFactory" in constructor and delegate sql execution to
dbutils. I always map connetion/transaction to Thread
it works very good for me in two tier web applications with MVC, I use
"closeIfOpen()" in single place per application
and transaction per request. It is good for JMS applications too,
"dispacher" handles all messages, invokes listeners,
commits transactions (if started) closes connection (if open).
>
> I'm happy to make this public in the current development version of
> dbutils. This is partly because I believe any unreleased software has the
> right to go and utterly change it in the future, so the users are
> accepting that risk [not as if forking a private version of dbutils is
> going to be stunningly painful to manage if need be]. [ie, no backwards
> compatibility worries until a first alpha, and even then not major worries
> until the 1.0 release].
>
> What do you think Juozas?
>
> Additionally, my vote is for having the Connection parameter at the front
> there and not hidden in thread locals. It complicates things I think to do
> otherwise.
>
> Hen
>
> On 21 Feb 2003, george stewart wrote:
>
> > Hi,
> >
> > Could the developers elaborate on reasons for having package access to
the interface ResultSetHandler?
> >
> > If this was public, user's could create objects without using the object
arrays.
> > If it ever becomes public, it would be nice to have something like this
in the package:
> >
> >
> > static void executeQuery(Connection connection, String query,
> > Object[] vals, ResultSetHandler rsh,
> > Collection cln
> > ) throws SQLException
> > {
> >
> > PreparedStatement stmt = null;
> > ResultSet rs = null;
> >
> > try {
> >
> > stmt = connection.prepareStatement(query);
> > fillStatement(stmt, vals);
> >
> > try{
> > rs = stmt.executeQuery();
> > while (rs.next()) {
> > cln.add(rsh.handle(rs));
> > }
> >
> > }catch(SQLException sqle){
> > String msg = sqle.getMessage() + " in query " + query +
> > java.util.Arrays.asList(vals).toString();
> > SQLException e = new SQLException(msg);
> > e.setNextException(sqle);
> > throw e;
> > }
> >
> > } finally {
> > closeQuietly(rs);
> > closeQuietly(stmt);
> > }
> >
> > }
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [dbutils] public access to ResultSetHandler
Posted by Henri Yandell <ba...@generationjava.com>.
I'm happy to make this public in the current development version of
dbutils. This is partly because I believe any unreleased software has the
right to go and utterly change it in the future, so the users are
accepting that risk [not as if forking a private version of dbutils is
going to be stunningly painful to manage if need be]. [ie, no backwards
compatibility worries until a first alpha, and even then not major worries
until the 1.0 release].
What do you think Juozas?
Additionally, my vote is for having the Connection parameter at the front
there and not hidden in thread locals. It complicates things I think to do
otherwise.
Hen
On 21 Feb 2003, george stewart wrote:
> Hi,
>
> Could the developers elaborate on reasons for having package access to the interface ResultSetHandler?
>
> If this was public, user's could create objects without using the object arrays.
> If it ever becomes public, it would be nice to have something like this in the package:
>
>
> static void executeQuery(Connection connection, String query,
> Object[] vals, ResultSetHandler rsh,
> Collection cln
> ) throws SQLException
> {
>
> PreparedStatement stmt = null;
> ResultSet rs = null;
>
> try {
>
> stmt = connection.prepareStatement(query);
> fillStatement(stmt, vals);
>
> try{
> rs = stmt.executeQuery();
> while (rs.next()) {
> cln.add(rsh.handle(rs));
> }
>
> }catch(SQLException sqle){
> String msg = sqle.getMessage() + " in query " + query +
> java.util.Arrays.asList(vals).toString();
> SQLException e = new SQLException(msg);
> e.setNextException(sqle);
> throw e;
> }
>
> } finally {
> closeQuietly(rs);
> closeQuietly(stmt);
> }
>
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org