Re: [DbUtils] Generalized ResultSet iterator

[David Graham <gr...@yahoo.com>]

--- Mikhail Krivoshein <in...@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

Re: [DbUtils] Generalized ResultSet iterator

[Mikhail Krivoshein <in...@mikkri.com>]

Hello David,

Thank you for your answer.

I think that this adds much value not because it is something hard to 
develop, but because it shows right way to use library
in this particular cases. So library user will be confident that in 
later library releases this approach will work.
I completely dislike idea of maintaining my own version of DbUtils that 
is compatible with my codebase.
I'd like to consider Jakarta commons project as vendor that gives me 
this library and I'd like to trust Jakarta commons project
in that library will stay backward and forward compatible during 
reasonable time frame.

And about your ResultSetRowHandler.

Lets consider case then you need to calculate summ of some funcation on 
particular query results.
It sounds reasonable to avoid in memory resultset version creation.
So to be flexible I'd recommend to develop generalized row processor and 
is able to produce result
of any type and then derive one row processor that will produce Lists 
and work as you described here.

>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



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