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
