dbm/ndbm notes and some code.

[Owen DeLong]

In article <13650 at ncoast.ORG> allbery at ncoast.UUCP (Brandon S. Allbery) writes:
%As quoted from <6847 at cbmvax.UUCP> by grr at cbmvax.UUCP (George Robbins):
%+---------------
%| In article <1889 at yunexus.UUCP> oz at 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