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

Adam Dickmeiss adam at indexdata.dk
Thu Nov 29 23:44:25 CET 2001


On Thu, Nov 29, 2001 at 03:22:05PM +0000, Ashley Sanders wrote:
> 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?

A result set must cache the records, true. But if a client
tries to have at most one result set alive, then it follows
that there's one cache and not two caches. So that client
will then not be able to inspect two records from two sets
since one of the sets was destroyed by the client. If the client
keeps both sets alive then there's no problem .. 

In previous mails I wrote a fragment that consulted the
Explain database. It's an example where I think it's elegant if the
API offers autonomous Explain records (you're not interested
in result sets from which they originated).

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

The user of the API must be careful to fetch all records
from first set before going to the second set when dealing
with targets that don't support named sets.

> > 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?
Sounds OK. If you do it the reference way then, according to
Scott Meyers, you should be careful in the design. To be honest,
it's the reason why I have second thoughts on the references.
See Item 23, 31 in Effective C++ (second edition). 

Now, my interpretation of Item 31, "Never return a reference
to a deferenced pointer initialized by new within the function"
is that we should NOT return an autonomous object. If we did
that would require us to delete it, and that's messy. So if
we stick to "returns reference owned by result set" we should be
OK. The reference is an ALIAS to something (inside the set) and
we cannot/should not delete it. With the clone method, however,
we should be able to create a record object.

Anyway, as Mike said, we're running in circles here. I vote
for his option 1). If it's better to do that with references
I won't argue against it.

-- Adam

> 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
> _______________________________________________
> ZOOM mailing list
> ZOOM at indexdata.dk
> http://www.indexdata.dk/mailman/listinfo/zoom

-- 
Adam Dickmeiss  mailto:adam at indexdata.dk  http://www.indexdata.dk
Index Data      T: +45 33410100           Mob.: 212 212 66



More information about the ZOOM mailing list