commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Krivoshein <i...@mikkri.com>
Subject [DbUtils] Generalized ResultSet iterator
Date Mon, 31 May 2004 15:37:36 GMT
Hello all!

I'd like to ask this question: is there any need in generalized 
ResultSet iterator?
(Except me, also, because I'd like to have it)

And the second and the third subquestions. How this iterator will be 
implemented and how general it will be?

At this moment I like three solutions:

1) Implement ResultSetHandler that will iterate through ResultSet and 
fill List with objects generated by
provided ResultSetHandler.

Example code:
=======================================================
public class ListHandler implements ResultSetHandler {
    /** ResultSet row handler */
    private final ResultSetHandler rowHandler;

    /**
     * Class constructor.
     *
     * @param rowHandler Handler called to generate object by resultset 
row. It
     *          is assumed that <code>ResultSetHandler</code> will scroll by
     *          one row each time.
     */
    public ListHandler(ResultSetHandler rowHandler) {
        this.rowHandler = rowHandler;
    }

    /**
     * Method handles list.
     */
    public Object handle(ResultSet rs) throws SQLException {
        List result = new ArrayList();
        while (!rs.isAfterLast()) {
            Object o = rowHandler.handle(rs);
            if(!rs.isAfterLast()) {
                result.add(o);
            }
        }
        return result;
    }
}
=======================================================
+ There is no need to define some kind of new interface to handle 
ResultSet rows only.
+ Suites well into existing code base.
- Assumes that rowHandler will scroll ResultSet by one row at the time.
- May generate only Lists. Doesn't suitable for handlers that perform 
some kind of counting against ResultSet data (I know about COUNT SQL 
function).

2) implement abstract ResultSetIterator that will be used to simplify 
iterating handlers development.

Example code:
=======================================================
abstract public class ResultSetIterator implements ResultSetHandler {
    /**
     * Method handles <code>ResultSet</code>.
     */
    public Object handle(ResultSet rs) throws SQLException {
        while(rs.next()) {
            Object o = this.handleRow(rs);
            this.countResult(o);
        }
        return this.getResult();
    }

    /**
     * Method responsible for handling currnet row data. It can't scroll 
<code>ResultSet</code> in any direction.
     */
    abstract protected Object handleRow(ResultSet rs) throws SQLException;

    /**
     * Method returns result of <code>ResultSet</code> handling. It is 
uncorrect to assume that this method will be called
     * only after <code>handleRow()</code>, in case of empty 
<code>ResultSet</code> it may be called immediatly.
     */
    abstract protected Object getResult(ResultSet rs);

    /**
     * Method counts row handling result into complete 
<code>ResultSet</code> handling result.
     */
    abstract protected void countResult(Object rowResult);
}
=======================================================
+ Having such class it is easy to implement generalized handlers that 
produce ArrayList and Object[].
+ Hightly generalized and may be used to develop any kinds of 
<code>ResultSet</code> iterators.
- Compatible with current code base, but doesn't suite well into it.
- Perhaps, this design is overkill for the problem.


3) Implement concrete ResultSetIterator but use row handlers implemented 
inside external classes.
So ResultSetIterator constructor will get one parameter of RowHandler 
type and provided RowHandler will
be responsible for implementing handleRow, countResult and getResult 
methods.

+ Having such class it is easy to implement generalized handlers that 
produce ArrayList and Object[].
+ Hightly generalized and may be used to develop any kinds of 
<code>ResultSet</code> iterators.
+ Suites well into existing code base design.
- Requires additional interface - RowHandler.
- Looks even more complicated than previous example.

Looking forward for comments, especially from voting developers and 
David Graham.

Best regards,
Mikhail Krivoshein

P.s. I'm using first approach now. It works well enough.



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