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. Tegan
----- Original Message ---- From: Chris Lamey <[EMAIL PROTECTED]> To: [email protected] 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! Cheers, Chris __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
