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] Generalized ResultSet iterator
Date Wed, 02 Jun 2004 02:10:20 GMT

--- Mikhail Krivoshein <info@mikkri.com> wrote:
> 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.

IMO, passing ResultSetHandlers into ResultSetHandlers is rather confusing
and makes it more complicated than it needs to be.

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

I've used something like this in the past; it's straightforward and easy
to understand.  I don't see a need for 3 methods though as handleRow() is
all you really need.

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

If we add this, I see it as a new ResultSetRowHandler class:
public abstract class ResultSetRowProcessor implements ResultSetHandler {

    public Object handle(ResultSet rs) throws SQLException {
        List rows = new ArrayList();
        while (rs.next()) {
            rows.add(this.processRow(rs));
        }
        return rows;
    }
    protected abstract Object handleRow(ResultSet rs) throws SQLException;
}

The question is how much value this actually adds to DbUtils?

David

> 
> Best regards,
> Mikhail Krivoshein
> 
> P.s. I'm using first approach now. It works well enough.


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.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