Extending iBATIS to support queryForIterator()

[Tegan Clark <te...@yahoo.com>]

Hi,
 
I've extended iBATIS to support a new method queryForIterator() which works in a manner similar to queryForList(), but returns an Iterator of the mapped objects rather than a List.  I've done this so that iBATIS can support potentially very large result sets in a manner that doesn't break the encapsulation around JDBC, i.e. it's objects in, objects out.
 
This solution differs from an approach that would use a RowHandler in that:
 
* I don't have to handle the row, iBATIS is still doing all of its magic for me.
* If I wish to perform some business logic etc on the returned result I can do this in a higher layer than the DAL.
* External API's that want to consume an Iterator can do so.
* I can stream the results straight out to a csv, servlet etc without having to implement something like a queue or file buffer.
 
I think this approach addresses 50% of the reasons everyone is asking for access to the ResultSet without breaking encapsulation.
 
Is this something the iBATIS community would be interested in having contributed?  I am of course happy to accept feedback and adapt my code to meet the needs of the broader iBATIS community or tune my internal strategy with expert advice.
 
Input appreciated.
 
Tegan

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

Re: Extending iBATIS to support queryForIterator()

[Larry Meadors <lm...@apache.org>]

Maybe I am just being incredibly dense here, but I honestly do not see
much value in this.

Please explain how this is an improvement to a RowHandler.

With a RowHandler, I do not have to load the entire result set into a List.

Iteration is done for me by iBATIS calling the row handler's
handleRow() method.

If I want to stream the results to a CSV or servlet, I do have to pass
the stream to the row handler, but it is still doable, and just as
easy to test.

The only thing that seems to be an improvement is that you could deal
with less that all of the rows - the RowHandler interface does not
allow that today, but could easily be extended to do so.

This to me seems like a lazy loading row handler, without a way of
making sure that you have done all that you want to with the rows so
that it can clean up the resources it used - for example, when is the
result set closed?

Larry


On 1/8/07, Tegan Clark <te...@yahoo.com> wrote:
>
> Hi,
>
> I've extended iBATIS to support a new method queryForIterator() which works
> in a manner similar to queryForList(), but returns an Iterator of the mapped
> objects rather than a List.  I've done this so that iBATIS can support
> potentially very large result sets in a manner that doesn't break the
> encapsulation around JDBC, i.e. it's objects in, objects out.
>
> This solution differs from an approach that would use a RowHandler in that:
>
> * I don't have to handle the row, iBATIS is still doing all of its magic for
> me.
> * If I wish to perform some business logic etc on the returned result I can
> do this in a higher layer than the DAL.
> * External API's that want to consume an Iterator can do so.
> * I can stream the results straight out to a csv, servlet etc without having
> to implement something like a queue or file buffer.
>
> I think this approach addresses 50% of the reasons everyone is asking for
> access to the ResultSet without breaking encapsulation.
>
> Is this something the iBATIS community would be interested in having
> contributed?  I am of course happy to accept feedback and adapt my code to
> meet the needs of the broader iBATIS community or tune my internal strategy
> with expert advice.
>
> Input appreciated.
>
> Tegan
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com