ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <brandon.goo...@gmail.com>
Subject Re: Extending iBATIS to support queryForIterator()
Date Mon, 08 Jan 2007 21:53:50 GMT
I appreciate your eagerness to contribute. However, I would opt against this
solution for a couple reasons.

1) It is not a contractually appropriate use of the iterator interface
2) The kind of processing you are talking about is not regularly handled by
iBATIS or any other form of JDBC abstraction (i.e. ORM). I'd use straight
JDBC in this case.

If we were to provide a means for this I'd rather see folks use iBATIS for
their SQL calls and get back a straight ResultSet to do with as they wish.
However, this would come at the cost of having to manage your own
connection.

I'm just speaking off the top of my head. I don't see this happening in
iBATIS 2. This seems most certainly a discussion for iB3.

Brandon

Larry,
>
> 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 it.
>
> 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.
>
> Tegan
>
> ----- 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?
>
> Larry
>
>
> 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
> http://mail.yahoo.com
>

Mime
View raw message