ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tegan Clark <tegan.cl...@yahoo.com>
Subject Re: Extending iBATIS to support queryForIterator()
Date Mon, 08 Jan 2007 20:31:04 GMT
Basically you've hit the nail on the head.  Without teaching grandma to suck eggs; in many
designs; the layer above the DAL is ignorant to the fact that iBATIS is the concrete implementation
and the DAL is ignorant to the business logic.  Lets present the example where we want to
return 50,000 records as either HTML (that's a big page!), XML or CSV back to the user's browser
for viewing or download (or as a web service).  The same 50,000 records are obtained from
the DAL, then processing is performed to format the output suitably.
In the row handler example I am forced to implement this transformation or HTML markup or
whatever, and associated business logic in my DAL, or develop some sought of queue or buffer,
or business logic delegate etc etc.  The interface to my DAL is now about presentation strategies
as well, not just data access.  All a bit dirty.  
iBATIS is simply a concrete data access strategy for me, my application isn't designed around
I cleanup when the Iterator hits the last record or by an explicit call to a repurposed remove().
That's my take anyway.  It's written and I'm happy to contribute it if the community sees
some value.

----- Original Message ----
From: Larry Meadors <lmeadors@apache.org>
To: user-java@ibatis.apache.org
Sent: Monday, January 8, 2007 11:10:02 AM
Subject: Re: Extending iBATIS to support queryForIterator()

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?


On 1/8/07, Tegan Clark <tegan.clark@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

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
View raw message