Personally this executeQuery call is almost identical to ones I write everywhere I
go... I don't think the executeQuery, should return any type of Iterator, but the
ResultSet itself. This avoids the whole memory issue for large result sets. If you're
passing a Connection you're not really hiding jdbc use anyway.
I normally make the interface:
ResultSet executeQuery(Connnection c, String sql, List params);
ResultSet executeQuery(Connnection c, String sql, List params, int[] types);
with versions for update and also allowing to pass a PreparedStatement in too (incase
it needs special preparation). The types int[] is so you can correctly set NULL values
with a null reference, on certain drivers (Sybase and (i think) Oracle).
If your looking to wrap the returned fields into a grid style object, then do so --
though this should be pluggable - maybe using a TableModel interface. I've used these
type of things in several jobs over too many years to remember. The functionality is
basically a PowerBuilder datastore / datawindow, with built in sorting /filtering
(should be easy with the commons.collections etc). I'm interested in this area, with
implementations using Axion db tables to store the data / provide SQL functionality in
the client / middle tier. Then you can layer HTML/Swing rendering on top and suddenly
db table driven apps are scarily quick to knock together.. :o)
________________
Ken Horn
OTC IT
Tel: 020 7545 1264
Henri Yandell
<bayard@generatio To: Jakarta Commons Developers
List <[EMAIL PROTECTED]>
njava.com> cc:
Subject: Re: [DBUtils][patch]
executeQuery method
22/11/2002 08:37
Please respond to
"Jakarta Commons
Developers List"
On Thu, 21 Nov 2002, Jeff Varszegi wrote:
> > What do you recommend on initial capacity
>
> I dunno, 50 or 100 would be nice. That's still a small result set
> size, and reduces copying a lot since I think that ArrayList defaults
> to 10 capacity, like most array-based structures in Java.
>
> > In this case, due to the nature of closing the ResultSet underneath,
> it is > unlikely the Iterators chief promise of lazy loading can be
> fulfilled
>
> Right!
>
> > should provide a common API. That
> > common API should have common ins and outs and Iterator is more generic
> > than a particular List, Map or Set
>
> I operate under two basic rules when I think about this sort of thing:
> 1. You should try to make things generic
> 2. You should never throw
> away (too many) useful things in the course of making something
> generic.
> If you had to, it means your abstraction is too generic for
> application in the domain, or needs to sit on top of another
> less-generic abstraction that provides more detailed support for when
> you'll need it
List has functionality which doesn't make sense in the context. Add,
remove, contains.
So a big 3) in your list is:
3) You should not offer up a partial API [ie) all the crap in Java with
'optional' methods. Iterator.remove etc.]
> > 1) ListIterator and not Iterator. We have a List, why not use it, as
> you said.
>
> That's a really good idea! All your comments are well-thought.
Basically I think that I need to have an ExtendedListIterator.
IteratorUtils.makeExtendedListIterator( List list ) {
return new ExtendedListIterator( list.iterator(), list.size() );
}
That is, if ListIterator just knew the size [and why can't it know that!
stupid API] then I'd feel secure to sit in a high castle shouting for
Iterators. :)
Maybe I can convince people that it could be in Collections.
Hen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
