[ZOOM] pointers (fwd)

Robert Sanderson azaroth at liverpool.ac.uk
Thu Nov 1 17:26:20 CET 2001

Froth.  Too many tasks at once. Will eventually remember not to just hit

> > As we all know, there's several implementations out there that don't
> > support named resultsets.  This means that the default resultset will be
> > reused for each search.
> But this is equally a problem whether you generate a new resultSet
> object with "conn->search()" or "new resultSet".  In all cases, you
> always have to be alive to the possibility that the server will
> suddenly decide not to bother supporting any or all of your result
> sets.  (This is true even if you only have one RS!)

I would think that a new resultSet implies that you will always create a
new object, whereas conn->search() could return an existing result set
object after it has been modified to the actual status of the resultset on
the server that it represents.

Search into named resultset foo.
Second Search into named resultset foo.

The initial resultset foo no longer exists anywhere apart from in the
object after the second search.  An implementation should be able to
realise this and reuse the old object, which new resultSet does not seem
to imply.

> Remember that _in abstract terms_ you still get your resultSet object
> from a connection (just as the abstract API says) -- it's just that,
> for pragmatic reasons, the way you _say_ that in the C++ binding will
> be "new resultSet(conn, query)".

Ahh.   The obvious problem of joining in half way through - it seemed that
this was to make it down to the abstract as well.  My bad, ignore my
objections (except perhaps above) :)


      ,'/:.          Rob Sanderson (azaroth at liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/

More information about the ZOOM mailing list