[jira] Created: (DBUTILS-48) Maintaining a parallel Java 1.5 version of DButils

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (DBUTILS-48) Maintaining a parallel Java 1.5 version of DButils

JIRA jira@apache.org
Maintaining a parallel Java 1.5 version of DButils
--------------------------------------------------

                 Key: DBUTILS-48
                 URL: https://issues.apache.org/jira/browse/DBUTILS-48
             Project: Commons DbUtils
          Issue Type: New Feature
            Reporter: Olivier Grégoire
            Priority: Minor


Well, DButils was a great step forward when managing a database. But Java 5 came and added a lot of new features to the language, including generics, which I think is easy to put in place.

The base change of all this is changing the signature of ResultSetHandler:

public interface ResultSetHandler<T> {
  public T handle(ResultSet rs) throws SQLException;
}

With this code, we can easily provide directly from the QueryRunner a specific object without having to cast it.

Furthermore, we can also make the queries much more efficient, and declare only 2 method instead of three as it is currently the case:

        public <T> T query(String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
                Connection connection = this.prepareConnection();
                try {
                        return this.query(connection, sql, handler, params);
                } finally {
                        close(connection);
                }
        }

        public <T> T query(Connection connection, String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
                PreparedStatement statement = null;
                ResultSet resultSet = null;

                try {
                        statement = this.prepareStatement(connection, sql);
                        this.fillStatement(statement, params);
                        resultSet = this.wrap(statement.executeQuery());
                        return handler.handle(resultSet);
                } catch (SQLException e) {
                        throw this.nestException(e, sql, params); // nestException creates an exception to be thrown here, instead of rethrow(e, sql, params);
                } finally {
                        try {
                                close(resultSet);
                        } finally {
                                close(statement);
                        }
                }
        }

I don't know for you, but I find that code much more readable and maintainable. In fact, I already did this implementation and use it in prod without any issue, since it is only basic language adaptation.

And using it is also very easy:

Book book = queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), title, author);

instead of

Book book = (Book)queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), new Object[]{title, author});

However, I wrote an original time estimation of 1 day, because all classes have to be adapted, especially those included in org.apache.common.dbutils.handlers.

As I estimate, it is minor, it is just a request in order to have more beautiful code, for a downside of providing a Java 1.5 compatible version of DBUtils. Maintaining this should be very rough as well, since DBUtils is not really big (but it's amazing how so little code can provide so much code improvements!)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (DBUTILS-48) Maintaining a parallel Java 1.5 version of DButils

JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/DBUTILS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated DBUTILS-48:
---------------------------------

         Fix Version/s: 1.2
    Remaining Estimate:     (was: 24h)
     Original Estimate:     (was: 24h)

Completely in favour of this - I think the solution is to focus on the DbUtils 1.5 compliant version rather than vice versa.

> Maintaining a parallel Java 1.5 version of DButils
> --------------------------------------------------
>
>                 Key: DBUTILS-48
>                 URL: https://issues.apache.org/jira/browse/DBUTILS-48
>             Project: Commons DbUtils
>          Issue Type: New Feature
>            Reporter: Olivier Grégoire
>            Priority: Minor
>             Fix For: 1.2
>
>
> Well, DButils was a great step forward when managing a database. But Java 5 came and added a lot of new features to the language, including generics, which I think is easy to put in place.
> The base change of all this is changing the signature of ResultSetHandler:
> public interface ResultSetHandler<T> {
>   public T handle(ResultSet rs) throws SQLException;
> }
> With this code, we can easily provide directly from the QueryRunner a specific object without having to cast it.
> Furthermore, we can also make the queries much more efficient, and declare only 2 method instead of three as it is currently the case:
> public <T> T query(String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> Connection connection = this.prepareConnection();
> try {
> return this.query(connection, sql, handler, params);
> } finally {
> close(connection);
> }
> }
> public <T> T query(Connection connection, String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> PreparedStatement statement = null;
> ResultSet resultSet = null;
> try {
> statement = this.prepareStatement(connection, sql);
> this.fillStatement(statement, params);
> resultSet = this.wrap(statement.executeQuery());
> return handler.handle(resultSet);
> } catch (SQLException e) {
> throw this.nestException(e, sql, params); // nestException creates an exception to be thrown here, instead of rethrow(e, sql, params);
> } finally {
> try {
> close(resultSet);
> } finally {
> close(statement);
> }
> }
> }
> I don't know for you, but I find that code much more readable and maintainable. In fact, I already did this implementation and use it in prod without any issue, since it is only basic language adaptation.
> And using it is also very easy:
> Book book = queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), title, author);
> instead of
> Book book = (Book)queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), new Object[]{title, author});
> However, I wrote an original time estimation of 1 day, because all classes have to be adapted, especially those included in org.apache.common.dbutils.handlers.
> As I estimate, it is minor, it is just a request in order to have more beautiful code, for a downside of providing a Java 1.5 compatible version of DBUtils. Maintaining this should be very rough as well, since DBUtils is not really big (but it's amazing how so little code can provide so much code improvements!)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (DBUTILS-48) Maintaining a parallel Java 1.5 version of DButils

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/DBUTILS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Fabulich updated DBUTILS-48:
--------------------------------

    Attachment: generics.patch

Here's a patch to update DbUtils for 1.5.  It's backwards-compatible with the old API; in fact, most of my changes are type-erased at compile time.

The biggest change was to change the order of the QueryRunner.query method signatures (var-args have to go at the end).  The old functions are left in, but deprecated.

I also added a helper static method ResultSetIterator.iterable, which returns an Iterable, for use in for-each loops.  You'd use it like this:

for (Object[] row : ResultSetIterator.iterable(resultSet) {
  // do stuff
}

> Maintaining a parallel Java 1.5 version of DButils
> --------------------------------------------------
>
>                 Key: DBUTILS-48
>                 URL: https://issues.apache.org/jira/browse/DBUTILS-48
>             Project: Commons DbUtils
>          Issue Type: New Feature
>            Reporter: Olivier Grégoire
>            Priority: Minor
>             Fix For: 1.2
>
>         Attachments: generics.patch
>
>
> Well, DButils was a great step forward when managing a database. But Java 5 came and added a lot of new features to the language, including generics, which I think is easy to put in place.
> The base change of all this is changing the signature of ResultSetHandler:
> public interface ResultSetHandler<T> {
>   public T handle(ResultSet rs) throws SQLException;
> }
> With this code, we can easily provide directly from the QueryRunner a specific object without having to cast it.
> Furthermore, we can also make the queries much more efficient, and declare only 2 method instead of three as it is currently the case:
> public <T> T query(String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> Connection connection = this.prepareConnection();
> try {
> return this.query(connection, sql, handler, params);
> } finally {
> close(connection);
> }
> }
> public <T> T query(Connection connection, String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> PreparedStatement statement = null;
> ResultSet resultSet = null;
> try {
> statement = this.prepareStatement(connection, sql);
> this.fillStatement(statement, params);
> resultSet = this.wrap(statement.executeQuery());
> return handler.handle(resultSet);
> } catch (SQLException e) {
> throw this.nestException(e, sql, params); // nestException creates an exception to be thrown here, instead of rethrow(e, sql, params);
> } finally {
> try {
> close(resultSet);
> } finally {
> close(statement);
> }
> }
> }
> I don't know for you, but I find that code much more readable and maintainable. In fact, I already did this implementation and use it in prod without any issue, since it is only basic language adaptation.
> And using it is also very easy:
> Book book = queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), title, author);
> instead of
> Book book = (Book)queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), new Object[]{title, author});
> However, I wrote an original time estimation of 1 day, because all classes have to be adapted, especially those included in org.apache.common.dbutils.handlers.
> As I estimate, it is minor, it is just a request in order to have more beautiful code, for a downside of providing a Java 1.5 compatible version of DBUtils. Maintaining this should be very rough as well, since DBUtils is not really big (but it's amazing how so little code can provide so much code improvements!)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (DBUTILS-48) Maintaining a parallel Java 1.5 version of DButils

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/DBUTILS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670809#action_12670809 ]

dfabulich edited comment on DBUTILS-48 at 2/5/09 8:30 AM:
-------------------------------------------------------------

Here's a patch to update DbUtils for 1.5.  It's backwards-compatible with the old API; in fact, most of my changes are type-erased at compile time.

The biggest change was to change the order of the QueryRunner.query method signatures (var-args have to go at the end).  The old functions are left in, but deprecated.

I also added a helper static method ResultSetIterator.iterable, which returns an Iterable, for use in for-each loops.  You'd use it like this:

{code}
for (Object[] row : ResultSetIterator.iterable(resultSet)) {
  // do stuff
}
{code}

      was (Author: dfabulich):
    Here's a patch to update DbUtils for 1.5.  It's backwards-compatible with the old API; in fact, most of my changes are type-erased at compile time.

The biggest change was to change the order of the QueryRunner.query method signatures (var-args have to go at the end).  The old functions are left in, but deprecated.

I also added a helper static method ResultSetIterator.iterable, which returns an Iterable, for use in for-each loops.  You'd use it like this:

for (Object[] row : ResultSetIterator.iterable(resultSet) {
  // do stuff
}
 

> Maintaining a parallel Java 1.5 version of DButils
> --------------------------------------------------
>
>                 Key: DBUTILS-48
>                 URL: https://issues.apache.org/jira/browse/DBUTILS-48
>             Project: Commons DbUtils
>          Issue Type: New Feature
>            Reporter: Olivier Grégoire
>            Priority: Minor
>             Fix For: 1.2
>
>         Attachments: generics.patch
>
>
> Well, DButils was a great step forward when managing a database. But Java 5 came and added a lot of new features to the language, including generics, which I think is easy to put in place.
> The base change of all this is changing the signature of ResultSetHandler:
> public interface ResultSetHandler<T> {
>   public T handle(ResultSet rs) throws SQLException;
> }
> With this code, we can easily provide directly from the QueryRunner a specific object without having to cast it.
> Furthermore, we can also make the queries much more efficient, and declare only 2 method instead of three as it is currently the case:
> public <T> T query(String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> Connection connection = this.prepareConnection();
> try {
> return this.query(connection, sql, handler, params);
> } finally {
> close(connection);
> }
> }
> public <T> T query(Connection connection, String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> PreparedStatement statement = null;
> ResultSet resultSet = null;
> try {
> statement = this.prepareStatement(connection, sql);
> this.fillStatement(statement, params);
> resultSet = this.wrap(statement.executeQuery());
> return handler.handle(resultSet);
> } catch (SQLException e) {
> throw this.nestException(e, sql, params); // nestException creates an exception to be thrown here, instead of rethrow(e, sql, params);
> } finally {
> try {
> close(resultSet);
> } finally {
> close(statement);
> }
> }
> }
> I don't know for you, but I find that code much more readable and maintainable. In fact, I already did this implementation and use it in prod without any issue, since it is only basic language adaptation.
> And using it is also very easy:
> Book book = queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), title, author);
> instead of
> Book book = (Book)queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), new Object[]{title, author});
> However, I wrote an original time estimation of 1 day, because all classes have to be adapted, especially those included in org.apache.common.dbutils.handlers.
> As I estimate, it is minor, it is just a request in order to have more beautiful code, for a downside of providing a Java 1.5 compatible version of DBUtils. Maintaining this should be very rough as well, since DBUtils is not really big (but it's amazing how so little code can provide so much code improvements!)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (DBUTILS-48) Maintaining a parallel Java 1.5 version of DButils

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/DBUTILS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated DBUTILS-48:
---------------------------------

    Fix Version/s:     (was: 1.2)

> Maintaining a parallel Java 1.5 version of DButils
> --------------------------------------------------
>
>                 Key: DBUTILS-48
>                 URL: https://issues.apache.org/jira/browse/DBUTILS-48
>             Project: Commons DbUtils
>          Issue Type: New Feature
>            Reporter: Olivier Grégoire
>            Priority: Minor
>         Attachments: generics.patch
>
>
> Well, DButils was a great step forward when managing a database. But Java 5 came and added a lot of new features to the language, including generics, which I think is easy to put in place.
> The base change of all this is changing the signature of ResultSetHandler:
> public interface ResultSetHandler<T> {
>   public T handle(ResultSet rs) throws SQLException;
> }
> With this code, we can easily provide directly from the QueryRunner a specific object without having to cast it.
> Furthermore, we can also make the queries much more efficient, and declare only 2 method instead of three as it is currently the case:
> public <T> T query(String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> Connection connection = this.prepareConnection();
> try {
> return this.query(connection, sql, handler, params);
> } finally {
> close(connection);
> }
> }
> public <T> T query(Connection connection, String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> PreparedStatement statement = null;
> ResultSet resultSet = null;
> try {
> statement = this.prepareStatement(connection, sql);
> this.fillStatement(statement, params);
> resultSet = this.wrap(statement.executeQuery());
> return handler.handle(resultSet);
> } catch (SQLException e) {
> throw this.nestException(e, sql, params); // nestException creates an exception to be thrown here, instead of rethrow(e, sql, params);
> } finally {
> try {
> close(resultSet);
> } finally {
> close(statement);
> }
> }
> }
> I don't know for you, but I find that code much more readable and maintainable. In fact, I already did this implementation and use it in prod without any issue, since it is only basic language adaptation.
> And using it is also very easy:
> Book book = queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), title, author);
> instead of
> Book book = (Book)queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), new Object[]{title, author});
> However, I wrote an original time estimation of 1 day, because all classes have to be adapted, especially those included in org.apache.common.dbutils.handlers.
> As I estimate, it is minor, it is just a request in order to have more beautiful code, for a downside of providing a Java 1.5 compatible version of DBUtils. Maintaining this should be very rough as well, since DBUtils is not really big (but it's amazing how so little code can provide so much code improvements!)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (DBUTILS-48) Maintaining a parallel Java 1.5 version of DButils

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/DBUTILS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Fabulich closed DBUTILS-48.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 1.3

Merged the java5 branch to trunk in revision 832220.

> Maintaining a parallel Java 1.5 version of DButils
> --------------------------------------------------
>
>                 Key: DBUTILS-48
>                 URL: https://issues.apache.org/jira/browse/DBUTILS-48
>             Project: Commons DbUtils
>          Issue Type: New Feature
>            Reporter: Olivier Grégoire
>            Priority: Minor
>             Fix For: 1.3
>
>         Attachments: generics.patch
>
>
> Well, DButils was a great step forward when managing a database. But Java 5 came and added a lot of new features to the language, including generics, which I think is easy to put in place.
> The base change of all this is changing the signature of ResultSetHandler:
> public interface ResultSetHandler<T> {
>   public T handle(ResultSet rs) throws SQLException;
> }
> With this code, we can easily provide directly from the QueryRunner a specific object without having to cast it.
> Furthermore, we can also make the queries much more efficient, and declare only 2 method instead of three as it is currently the case:
> public <T> T query(String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> Connection connection = this.prepareConnection();
> try {
> return this.query(connection, sql, handler, params);
> } finally {
> close(connection);
> }
> }
> public <T> T query(Connection connection, String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> PreparedStatement statement = null;
> ResultSet resultSet = null;
> try {
> statement = this.prepareStatement(connection, sql);
> this.fillStatement(statement, params);
> resultSet = this.wrap(statement.executeQuery());
> return handler.handle(resultSet);
> } catch (SQLException e) {
> throw this.nestException(e, sql, params); // nestException creates an exception to be thrown here, instead of rethrow(e, sql, params);
> } finally {
> try {
> close(resultSet);
> } finally {
> close(statement);
> }
> }
> }
> I don't know for you, but I find that code much more readable and maintainable. In fact, I already did this implementation and use it in prod without any issue, since it is only basic language adaptation.
> And using it is also very easy:
> Book book = queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), title, author);
> instead of
> Book book = (Book)queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), new Object[]{title, author});
> However, I wrote an original time estimation of 1 day, because all classes have to be adapted, especially those included in org.apache.common.dbutils.handlers.
> As I estimate, it is minor, it is just a request in order to have more beautiful code, for a downside of providing a Java 1.5 compatible version of DBUtils. Maintaining this should be very rough as well, since DBUtils is not really big (but it's amazing how so little code can provide so much code improvements!)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (DBUTILS-48) Java 1.5 generics and varargs

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/DBUTILS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Fabulich updated DBUTILS-48:
--------------------------------

    Summary: Java 1.5 generics and varargs  (was: Maintaining a parallel Java 1.5 version of DButils)

> Java 1.5 generics and varargs
> -----------------------------
>
>                 Key: DBUTILS-48
>                 URL: https://issues.apache.org/jira/browse/DBUTILS-48
>             Project: Commons DbUtils
>          Issue Type: New Feature
>            Reporter: Olivier Grégoire
>            Priority: Minor
>             Fix For: 1.3
>
>         Attachments: generics.patch
>
>
> Well, DButils was a great step forward when managing a database. But Java 5 came and added a lot of new features to the language, including generics, which I think is easy to put in place.
> The base change of all this is changing the signature of ResultSetHandler:
> public interface ResultSetHandler<T> {
>   public T handle(ResultSet rs) throws SQLException;
> }
> With this code, we can easily provide directly from the QueryRunner a specific object without having to cast it.
> Furthermore, we can also make the queries much more efficient, and declare only 2 method instead of three as it is currently the case:
> public <T> T query(String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> Connection connection = this.prepareConnection();
> try {
> return this.query(connection, sql, handler, params);
> } finally {
> close(connection);
> }
> }
> public <T> T query(Connection connection, String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> PreparedStatement statement = null;
> ResultSet resultSet = null;
> try {
> statement = this.prepareStatement(connection, sql);
> this.fillStatement(statement, params);
> resultSet = this.wrap(statement.executeQuery());
> return handler.handle(resultSet);
> } catch (SQLException e) {
> throw this.nestException(e, sql, params); // nestException creates an exception to be thrown here, instead of rethrow(e, sql, params);
> } finally {
> try {
> close(resultSet);
> } finally {
> close(statement);
> }
> }
> }
> I don't know for you, but I find that code much more readable and maintainable. In fact, I already did this implementation and use it in prod without any issue, since it is only basic language adaptation.
> And using it is also very easy:
> Book book = queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), title, author);
> instead of
> Book book = (Book)queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), new Object[]{title, author});
> However, I wrote an original time estimation of 1 day, because all classes have to be adapted, especially those included in org.apache.common.dbutils.handlers.
> As I estimate, it is minor, it is just a request in order to have more beautiful code, for a downside of providing a Java 1.5 compatible version of DBUtils. Maintaining this should be very rough as well, since DBUtils is not really big (but it's amazing how so little code can provide so much code improvements!)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (DBUTILS-48) Java 1.5 generics and varargs

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/DBUTILS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Fabulich updated DBUTILS-48:
--------------------------------

    Priority: Critical  (was: Minor)

> Java 1.5 generics and varargs
> -----------------------------
>
>                 Key: DBUTILS-48
>                 URL: https://issues.apache.org/jira/browse/DBUTILS-48
>             Project: Commons DbUtils
>          Issue Type: New Feature
>            Reporter: Olivier Grégoire
>            Priority: Critical
>             Fix For: 1.3
>
>         Attachments: generics.patch
>
>
> Well, DButils was a great step forward when managing a database. But Java 5 came and added a lot of new features to the language, including generics, which I think is easy to put in place.
> The base change of all this is changing the signature of ResultSetHandler:
> public interface ResultSetHandler<T> {
>   public T handle(ResultSet rs) throws SQLException;
> }
> With this code, we can easily provide directly from the QueryRunner a specific object without having to cast it.
> Furthermore, we can also make the queries much more efficient, and declare only 2 method instead of three as it is currently the case:
> public <T> T query(String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> Connection connection = this.prepareConnection();
> try {
> return this.query(connection, sql, handler, params);
> } finally {
> close(connection);
> }
> }
> public <T> T query(Connection connection, String sql, ResultSetHandler<T> handler, Object... params) throws SQLException {
> PreparedStatement statement = null;
> ResultSet resultSet = null;
> try {
> statement = this.prepareStatement(connection, sql);
> this.fillStatement(statement, params);
> resultSet = this.wrap(statement.executeQuery());
> return handler.handle(resultSet);
> } catch (SQLException e) {
> throw this.nestException(e, sql, params); // nestException creates an exception to be thrown here, instead of rethrow(e, sql, params);
> } finally {
> try {
> close(resultSet);
> } finally {
> close(statement);
> }
> }
> }
> I don't know for you, but I find that code much more readable and maintainable. In fact, I already did this implementation and use it in prod without any issue, since it is only basic language adaptation.
> And using it is also very easy:
> Book book = queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), title, author);
> instead of
> Book book = (Book)queryRunner.query("SELECT * FROM book WHERE title = ? AND author = ?", new BeanHandler(Book.class), new Object[]{title, author});
> However, I wrote an original time estimation of 1 day, because all classes have to be adapted, especially those included in org.apache.common.dbutils.handlers.
> As I estimate, it is minor, it is just a request in order to have more beautiful code, for a downside of providing a Java 1.5 compatible version of DBUtils. Maintaining this should be very rough as well, since DBUtils is not really big (but it's amazing how so little code can provide so much code improvements!)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.