dbm/ndbm notes and some code.

[Brandon S. Allbery]

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.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery at ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery at hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser