commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: [DbUtils] QueryRunner.executeAction(s) - Inversion of Control pattern applied
Date Fri, 04 Jun 2004 18:11:48 GMT

--- Mikhail Krivoshein <info@mikkri.com> wrote:
> Hello all,
> 
> Today I found one disadvantage of DbUtils QueryRunner class.
> Why I use it? Because it makes database connections management very 
> straightforward
> and simplifies queries execution. But what happens if you need to 
> execute something
> really complex?

Then you probably need to use straight JDBC.  DbUtils isn't meant to hide
JDBC, just make the simple cases easier to code.  Complex transaction
logic is not something DbUtils is designed to handle.

> 
> I have need to execute four statements as one database action:
> =============================================================
>             try {
>                 runner.update(conn, "LOCK TABLES keyword WRITE");
>                 runner.update(
>                     conn,
>                     "DELETE FROM keyword WHERE service_id = ?",
>                     serviceIdInt);
>                 runner.batch(
>                     conn,
>                     "INSERT INTO keyword (keyword, service_id) VALUES 
> (?,?)",
>                     data);
>             } finally {
>                 runner.update(conn, "UNLOCK TABLES");
>             }
> =============================================================
> 
> Problem is that I need to use the same database connection to execute 
> all of them.
> So I'm forced to manage database connection by myself. Oops. That is 
> exactly why
> I'm started to use DbUtils package.
> 
> Lets make one step back. How QueryRunner is usually used? Developer call
> 
> its methods,
> such as query() and pass ResultSetHandler that gathers data from query 
> results.
> This is very close to Inversion of Control design pattern.
> 
> So my proposal is to make one step forward and implement pure IoC style 
> methods
> void executeAction(DatabaseAction action) and void 
> executeActions(DatabaseAction[] actions).

I realize IoC is a popular buzzword these days but this is actually a
simple application of the GoF Strategy pattern, not IoC.

> 
> My example will looks like this after such change:
> =============================================================
> runner.executeActions(
>     new DatabaseAction[] {
>         runner.newUpdateAction("LOCK TABLES keyword WRITE"),
>         runner.newUpdateAction("DELETE FROM keyword WHERE service_id =
> ?",
>                     serviceIdInt),
>         runner.newUpdateAction("INSERT INTO keyword (keyword, 
> service_id) VALUES (?,?)",
>                     data),
>         runner.newUpdateAction("UNLOCK TABLES");
>     });
> =============================================================
> I consider this code very straighforward.

IMO, you've replaced easy to understand JDBC transaction code with a
proprietary transaction API in DbUtils.  What happens when one of the
steps in the transaction is a query?  What do we do with the ResultSet? 
How do we handle errors?  I assume you want to unlock the table regardless
of a failure but we have no clear way of implementing that.  There are too
many variations on what the transaction needs to do to hide them all
behind a DbUtils API.

David

> 
> Looking forward for comments and suggestions.
> 
> Best regards,
> Mikhail Krivoshein
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message