You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Eric Alexander <er...@genscape.com> on 2002/11/21 23:21:04 UTC

[DBUtils][patch] executeQuery method

Here's a patch to DBUtils that adds an executeQuery method:

public static Iterator executeQuery(Connection connection, String query,
Object[] vals) throws SQLException

If null is found in the Object[], it will get passed to the driver. There's
probably something better we can do with it, but it's a start.


Re: [DBUtils][patch] executeQuery method

Posted by Henri Yandell <ba...@generationjava.com>.
Applied.

On Thu, 21 Nov 2002, Eric Alexander wrote:

> Here's a patch to DBUtils that adds an executeQuery method:
>
> public static Iterator executeQuery(Connection connection, String query,
> Object[] vals) throws SQLException
>
> If null is found in the Object[], it will get passed to the driver. There's
> probably something better we can do with it, but it's a start.
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [DBUtils][patch] executeQuery method

Posted by Henri Yandell <ba...@generationjava.com>.

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [DBUtils][patch] executeQuery method

Posted by Jeff Varszegi <jv...@yahoo.com>.
> 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

> 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.

Jeff


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [DBUtils][patch] executeQuery method

Posted by Henri Yandell <ba...@generationjava.com>.
What do you recommend on initial capacity. On reflection I'm not sure on
my +1 as anyone using this method for LARGE result sets should not be
using it [memory etc].

I'm going to rollout the usual argument. If I use an Iterator then I can
choose whether to load easily. I can also implement an extension far
easier as List is a large and heavy API.

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,
though PagingIterator which extends Iterator and adds a close() method
[which must be called] could be implemented. [not saying it should, it has
issues].

However, I think DbUtils as a class 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. It might be that there are obvious
performance reasons to choose a particular return format, like List,
SynchronisedList or Map, but I don't think that should happen often.

On the minus side for Iterators, they imply an open-ness, that we have
some kind of resource cursor [not db, just language] linking to some
structure that someone else might own. In many cases returning a structure
rather than a view [like Iterator] makes sense then because we want to
deal in discrete operations, but this code replaces code that currently
uses the ResultSet.next pattern, so I don't think that -ve for Iterators
applies here.

Things that might make sense though:

1) ListIterator and not Iterator. We have a List, why not use it, as you
said.

2) Knowing the size. This does make List tempting.

My tuppence.

Hen

On Thu, 21 Nov 2002, Jeff Varszegi wrote:

> Iterator is the worst thing that ever happened to the Collections API
> (because of its omnipresence, not its presence).  I think it's way
> overused because people have talked too much about how it's a simple
> generic abstraction.  The fact is, it's very often the case in use of
> a data structure that you want to get the elements in a less
> restrictive way than Iterator provides.

>  When was the last time you called a HashMap's keySet().iterator()
> method in order to find the thing you were looking for?  Why do
> ArrayLists exist in the first place?  Iterators suck in a lot of
> respects, because you have to create a new object for every pass over
> some data that's already wrapped up in (usually a lot of) objects, and
> you incur extra performance penalty for every all those method calls.
> This stuff really adds up.
>
> I would try to avoid any but forward-only or backward-only reads in my
> own database programming, but it's sometimes necessary to look at a
> value previously returned from a ResultSet.  The best schemes don't
> rely on the result set itself, but cache stuff that will be needed
> later.  The way the method is implemented, EVERYTHING is cached in
> memory already, and the fact that you get an Iterator back doesn't
> change that, it only restricts your ability to index into the data.
> You also lose the ability right off the bat to know how many rows were
> returned, even though everything is sitting right in memory.
>
> Jeff
>
> --- Henri Yandell <ba...@generationjava.com> wrote:
> >
> > initial capacity, +1.
> >
> > Iterator will need arguing. I don't believe people need to get collections
> > back from an API, they need the lowest common denominator and my view is
> > that this is an iterator.
> >
> > It's something that always starts arguments though :)
> >
> > Hen
> >
> > On Thu, 21 Nov 2002, Jeff Varszegi wrote:
> >
> > > Looks okay, except I think you should make the initial capacity of the ArrayList bigger
> > perhaps.
> > > I don't know.  Also, I would way rather have the ArrayList for my database-lookup trouble than
> > > some ListIterator that I can only use once.
> > >
> > > My 1.5 cents,
> > >
> > > Jeff
> > >
> > > --- Eric Alexander <er...@genscape.com> wrote:
> > > > Here's a patch to DBUtils that adds an executeQuery method:
> > > >
> > > > public static Iterator executeQuery(Connection connection, String query,
> > > > Object[] vals) throws SQLException
> > > >
> > > > If null is found in the Object[], it will get passed to the driver. There's
> > > > probably something better we can do with it, but it's a start.
> > > >
> > > >
> > >
> > > > ATTACHMENT part 2 application/octet-stream name=DbUtils.patch
> > > > --
> > > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
> > > http://mailplus.yahoo.com
> > >
> > > --
> > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [DBUtils][patch] executeQuery method

Posted by Jeff Varszegi <jv...@yahoo.com>.
Iterator is the worst thing that ever happened to the Collections API (because of its
omnipresence, not its presence).  I think it's way overused because people have talked too much
about how it's a simple generic abstraction.  The fact is, it's very often the case in use of a
data structure that you want to get the elements in a less restrictive way than Iterator provides.
 When was the last time you called a HashMap's keySet().iterator() method in order to find the
thing you were looking for?  Why do ArrayLists exist in the first place?  Iterators suck in a lot
of respects, because you have to create a new object for every pass over some data that's already
wrapped up in (usually a lot of) objects, and you incur extra performance penalty for every all
those method calls.  This stuff really adds up.

I would try to avoid any but forward-only or backward-only reads in my own database programming,
but it's sometimes necessary to look at a value previously returned from a ResultSet.  The best
schemes don't rely on the result set itself, but cache stuff that will be needed later.  The way
the method is implemented, EVERYTHING is cached in memory already, and the fact that you get an
Iterator back doesn't change that, it only restricts your ability to index into the data.  You
also lose the ability right off the bat to know how many rows were returned, even though
everything is sitting right in memory.

Jeff

--- Henri Yandell <ba...@generationjava.com> wrote:
> 
> initial capacity, +1.
> 
> Iterator will need arguing. I don't believe people need to get collections
> back from an API, they need the lowest common denominator and my view is
> that this is an iterator.
> 
> It's something that always starts arguments though :)
> 
> Hen
> 
> On Thu, 21 Nov 2002, Jeff Varszegi wrote:
> 
> > Looks okay, except I think you should make the initial capacity of the ArrayList bigger
> perhaps.
> > I don't know.  Also, I would way rather have the ArrayList for my database-lookup trouble than
> > some ListIterator that I can only use once.
> >
> > My 1.5 cents,
> >
> > Jeff
> >
> > --- Eric Alexander <er...@genscape.com> wrote:
> > > Here's a patch to DBUtils that adds an executeQuery method:
> > >
> > > public static Iterator executeQuery(Connection connection, String query,
> > > Object[] vals) throws SQLException
> > >
> > > If null is found in the Object[], it will get passed to the driver. There's
> > > probably something better we can do with it, but it's a start.
> > >
> > >
> >
> > > ATTACHMENT part 2 application/octet-stream name=DbUtils.patch
> > > --
> > > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
> > http://mailplus.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [DBUtils][patch] executeQuery method

Posted by Henri Yandell <ba...@generationjava.com>.
initial capacity, +1.

Iterator will need arguing. I don't believe people need to get collections
back from an API, they need the lowest common denominator and my view is
that this is an iterator.

It's something that always starts arguments though :)

Hen

On Thu, 21 Nov 2002, Jeff Varszegi wrote:

> Looks okay, except I think you should make the initial capacity of the ArrayList bigger perhaps.
> I don't know.  Also, I would way rather have the ArrayList for my database-lookup trouble than
> some ListIterator that I can only use once.
>
> My 1.5 cents,
>
> Jeff
>
> --- Eric Alexander <er...@genscape.com> wrote:
> > Here's a patch to DBUtils that adds an executeQuery method:
> >
> > public static Iterator executeQuery(Connection connection, String query,
> > Object[] vals) throws SQLException
> >
> > If null is found in the Object[], it will get passed to the driver. There's
> > probably something better we can do with it, but it's a start.
> >
> >
>
> > ATTACHMENT part 2 application/octet-stream name=DbUtils.patch
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [DBUtils][patch] executeQuery method

Posted by Jeff Varszegi <jv...@yahoo.com>.
Looks okay, except I think you should make the initial capacity of the ArrayList bigger perhaps. 
I don't know.  Also, I would way rather have the ArrayList for my database-lookup trouble than
some ListIterator that I can only use once.

My 1.5 cents,

Jeff

--- Eric Alexander <er...@genscape.com> wrote:
> Here's a patch to DBUtils that adds an executeQuery method:
> 
> public static Iterator executeQuery(Connection connection, String query,
> Object[] vals) throws SQLException
> 
> If null is found in the Object[], it will get passed to the driver. There's
> probably something better we can do with it, but it's a start.
> 
> 

> ATTACHMENT part 2 application/octet-stream name=DbUtils.patch
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>