[ZOOM] Re: Ouch

Ashley Sanders zzaascs at irwell.mimas.ac.uk
Thu Nov 1 16:32:58 CET 2001


Adam, Mike,

> I thought this was not such a big issue, but it's essential. The search
> method in its current form doesn't allow that you specialize your
> resultSet (inherit from it). Let me show some code. I hope it
> speaks for itself.
>
> class smartSet : public resultSet {
> public:
>     smartSet(connection *c, query *q);
> };
> 
> smartSet::smartSet(connection *c, query *q) : resultSet(c, q)
> {
>     // stuff for my smartSet
> }
> 
> record *give_me_targetinfo3 (connection *c)
> {
>     prefixQuery q("@attr exp1 1=1 targetinfo");
>     smartSet (c, &q);                    // works
>     smartSet *s = new smartSet(c, &q);   // works too
>     smartSet *s1 = c->search(&q);        // works not
>     record *rec = s->getRecord(0);       // works (with smartSet)
>     // not deleting ... TODO
>     return rec;
> }
> 

Indeed. What you've suggested above and what we now seem to be
converging on is getting very similar to my COPAC origin. The one
major difference we between ZOOM and COPAC is the connection
object. And I'm throwing this in now as we seem to be in the mood
for changing everything. The ZOOM connection object is a single
connection to one target. In COPAC the connection object can talk
to more than one target. So when a resultSet object is created
the connection object sends the search to as many targets as
specfied by the query. Do we want to go down this route Mike?

Is it also worth defining a protocol class for a resultSet
heirarchy -- ie as base class from which all resultSet classes
are derived?

Ashley.

-- 
Ashley Sanders                                a.sanders at mcc.ac.uk
COPAC: A public bibliographic database from MIMAS, funded by JISC
             http://copac.ac.uk/ - copac at mimas.ac.uk



More information about the ZOOM mailing list