[ZOOM] ZOOM 1.0-g.hh OK (sas Re: zoom.hh)

Ashley Sanders zzaascs at irwell.mimas.ac.uk
Thu Nov 29 16:22:05 CET 2001


Adam,

> Certainly I can see a use for a autonomous record object. What
> happens if you need to search twice on a target that doesn't
> support named result sets? Well, maybe the client is smart enough
> to keep the records in caches, maybe not.

If we are having the resultSet own the records, then it follows
that the resultSet object _MUST_ cache the records -- else what
can it return a reference or a pointer to?

Even so, a cache doesn't solve the no named result sets problem.
A cache will ameliorate the problem a little. But if result set
Q1 was only partly cached before we created result set Q2, then
when we go back to Q1 we have a potential problem. There is no
easy way around this other than making sure all records are
cached before creating another result set (or having the query
Q1 re-run somehow.) We could provide a new member function
to resultSet called, say, resultSet::populate (size_t sz)
which tells the result set to retrieve all records up to
sz. Then the user will know where they stand.

> If we stick to pointers and clone, I think we're OK. So what I'm saying
> is that I'm happy with zoom-1.0g.hh as it is.

And just as I'm getting to like the references too.

I don't think there would be a problem with keeping the clone()
function with the reference model? Then you could have the best
of both worlds?

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