[ZOOM] pointers (fwd)

Mike Taylor mike at tecc.co.uk
Thu Nov 1 17:14:20 CET 2001

> Date: Thu, 1 Nov 2001 15:26:34 +0000 (GMT)
> From: Robert Sanderson <azaroth at liverpool.ac.uk>
> > I suggest that we take the bold step of _throwing away_ the search()
> > method from the ZOOM::connection class, and _replace_ it with a
> > resultSet constructor whose arguments are a connection and a query.
> I have two main concerns with this approach:
> 1)
> From the API:
> "A result set represents a set of records, held on a server, which
> have been identified by searching."
> 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 think it's counter productive to assume that a 'new' resultset
> will be created for a search.  In fact, a well behaved
> implementation would reuse a named resultset object for a search
> that returns its results with the same name rather than creating a
> new object with the same name, which is what is implied from a
> search via a constructor.

Sorry, I don't follow this at all.

> 2)
> If you have to have a resultset to do a search, then how do we
> implement scan?  I expected that it would simply be a scan()
> function on the connection object.  If search is on a resultset,
> then scan would need some other object to be called on to be
> consistent.

I don't see the problem here.  Scan looks to me like it's an obvious
fit for a method on the connection class.  Where's the difficulty

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

> Under the Search documentation, "If the search fails..., then an
> exception may be thrown or an undefined value may be returned."

Yup.  I used this form of language throughout the document precisely
because I was aware of the fact that you can't "return an error" from
a constructor in C++ -- unlike, say, Perl, in which you just have your
new() method return an undefined value.

So if a C++ constructor fails (whether ZOOM::connection::connection()
not being able to resolve a hostname, or ZOOM::resultSet::resultSet()
running out of memory, or discovering that the server doesn't support
the specified attributes, or whatever) an exception must be thrown.
And that is the purpose of the ZOOM::error classes that Heikki
wondered about in his depressing message which I really will summon up
the willpower to reply to RSN :-)

> If it's a constructor, then obviously only an object of the
> appropriate type should be returned.  While this isn't a bad thing
> (TIOWTDI) it does assume a certain style of error handling which may
> make no sense in a particular implementation.

The style is assumes is exception handling, yes.

Is that a problem?  Are there any non-toy C++ compilers left that
don't comfortably handle exceptions?  (PLEASE don't tell me that G++
still doesn't do this, or I shall just cry.)

> If there is an error in creating the result set object as opposed to
> an error from the search, how is this to be represented?  I would
> expect in two different ways as one is an internal problem, the
> other is out of the code's control at the server end.

Hence two subclasses of ZOOM::error -- systemError for the former, and
bib1Error for the latter.  (You could argue that "bib1" is a nasty
detail that should be hidden from the name, BTW.)

> Search error could be: Did not return a response PDU.  Creating a
> result set for this is ludicrous - not only doesn't the resultset
> exist, there's no more connection! The connection object needs to be
> able to reflect this, and it seems strange that a resultset object
> would close a connection object, rather than the connection object
> closing itself.

Result sets objects should not mess with their parents!

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "I never make predictions and I never will" -- Paul

More information about the ZOOM mailing list