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 Tue, 09 Jan 2007 15:52:12 GMT
Thanks guys for all the very valuable expert input.
They are all very valid points that I hadn't considered in the bigger picture, especially
the encapsulation of the connection closing.  I had hoped to add to iBATIS by using resource
that needed to be applied for my project.  For just my requirement, I've decided to take a
much simpler approach of just grabbing the ResultSet then doing my own thing.
Thanks again for the advice, it's appreciated.

----- Original Message ----
From: Chris Lamey <clamey@localmatters.com>
To: user-java@ibatis.apache.org
Sent: Monday, January 8, 2007 4:09:09 PM
Subject: Re: Extending iBATIS to support queryForIterator()

On Mon, 2007-01-08 at 15:53 -0700, Clinton Begin wrote:
> So Tegan, I'm thinking about this, and I'm still not quite sure what
> this Iterator buys you...
> Why couldn't you just do:
> return sqlMapper.queryForList("getMyList", params, skip,
> max).iterator(); 

Right, but I think Tegan is saying that since it's known that there's a
bunch of things to stream out, there shouldn't have to be a
queue/buffer/chunk setup.  It should just be able to stream back results
without having to manage the skip/max stuff.

One thing I don't like about the Iterator mechanism is that you're
expecting your high-level code to care about result sets.  Specifically
that code would have to handle the close of the result set correctly.
The overloaded remove() method to close() seems non-obvious for a
well-used open source library, and I wouldn't trust that the iterator
would exhaust and close the result set correctly in all cases.

If I had to pick between my DAL knowing about some presentation logic or
expecting my presentation logic to close result sets correctly, I'd want
the DAL to be less clean.

For the issue of streaming back 50K HTML, CSV, or XML items, the
RowHandler seems like a decent solution.  I'd probably pass a
presentation level transformer implementing a generic transform
interface with an output stream down to a RowHandler from the top level
code.  The transform would be called on the RowHandler's result map and
its output would go right into the output stream.  That way the
interface to the DAL is fairly generic and logical (if you're writing to
an output stream, you might want to transform it first), and the
presentation strategy is defined in an upper layer.  Having your
presentation layer transformer know about a Map with column names as
keys is kind of weak, but it is generic.

Ah, the joys of impedance mismatch, where well-intentioned OO code meets
the ugly reality of relational databases!


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