Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!sun-barr!male!asilomar!owend
From: owend@asilomar.sun.COM (Owen DeLong)
Newsgroups: comp.unix.wizards
Subject: Re: dbm/ndbm notes and some code.
Message-ID: <670@male.ebay.Sun.COM>
Date: 19 May 89 00:58:24 GMT
References: <1889@yunexus.UUCP> <6847@cbmvax.UUCP> <13650@ncoast.ORG>
Sender: news@male.ebay.Sun.COM
Reply-To: owend@asilomar.EBay.Sun.COM (Owen DeLong)
Organization: Sun Microsystems, Inc.  Mt. View, Ca.
Lines: 31

In article <13650@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
%As quoted from <6847@cbmvax.UUCP> by grr@cbmvax.UUCP (George Robbins):
%+---------------
%| In article <1889@yunexus.UUCP> oz@yunexus.UUCP (Ozan Yigit) writes:
%| > This is where the "database traversal" turns into a pumpkin.  Because of
%| > internal caching of the key position for dbm_nextkey (dbm_keyptr ??),
%| > which is appearently NOT adjusted for deletions, this traversal will never
%| > display the key right after the one just deleted. Workaround is to save
%| > all keys to be deleted, then perform all deletions once the sequential
%| > traversal is complete.
%| 
%| Say what?  Where are you going to save this potentially unbounded list of
%| to be deleted keys?  Surely there is a better solution???
%+---------------
%
%This is true, at least for dbm.  I discovered it when I wrote the "history
%expire" program for my comp.sources.misc submission handler (now defunct,
%but soon to return... I don't want to have to remember what articles already
%came through so I can trash dups).  My solution was to change the delete()
%to a write() to a temporary file, then rewind the temp file at the end of
%the scan and call delete() on every key in it.  Ugh.
%
Huh?  Isn't what you are saying eaxctly what the first paragraph reccommends?
Save the potentially unbounded list of to be deleted keys in a temp file, then
perform all deletions once the sequential traversal is complete.  The second
paragraph was looking for a better solution (i.e. one which allowed single
traversal of the database, with reads, and deletes continuing.)  I don't know
enough about dbm to offer such a solution, but _HOPEFULLY_ this clarification
will attract someone who does... I'd also be interested in the answer.

Owen