pseudo-collections representation of traversal results is inefficient

[GoogleCodeExporter]

What steps will reproduce the problem?

See below.

What is the expected output? What do you see instead?

The pseudo-collections representation of traversal results is inefficient,
and I'm not sure what we're gaining to balance that.  We need a single
ResultSet instance and a ResultSet Iterator instance, a PropertyMap
instance and a PropertyMap Iterator instance per row, a Property instance
and a values Iterator per column, and a Value instance per value. If the
backing store is a java.sql.ResultSet or similar, this is hugely
inefficient. If the design were reversed, a java.sql.ResultSet-like
interface could be implemented on top of Collections in a straightforward
fashion.
In my case, since I have a java.sql.ResultSet-like backing store, I have
classes whose sole job is remembering which row and column we're on. This
produces thousands of extra objects per ResultSet.

I did think of being tricky. If the ResultSet is processed once, with only
a single iterator per ResultSet, per PropertyMap, and per Property, then I
think it's possible to implement this design in about a third as many
objects, all but two of them Value instances. This is still pretty bad
compared to a java.sql.ResultSet.

Note that I'm not suggesting that a java.sql.ResultSet should be used
as-is, just that the single interface including row traversal, column
traversal, and data conversion is more efficient.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by donald.z...@gmail.com on 24 Jan 2007 at 3:38

[GoogleCodeExporter]

Google Bug #243992

Original comment by vjo...@gmail.com on 9 Feb 2007 at 4:31

[GoogleCodeExporter]

Started refactor in r616 and finished in r627.

Original comment by mgron...@gmail.com on 3 Oct 2007 at 10:01

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by mgron...@gmail.com on 3 Oct 2007 at 10:51

• Added labels: Milestone-Release_1.0.0