in reply to tied hashed and deleting keys and their valeus

Your problem with the key being in the DB file. It's in the docs of BerkeleyDB (v3):
Space freed by deleting key/data pairs from a Btree or Hash database is never returned to the filesystem, although it is reused where possible. This means that the Btree and Hash databases are grow-only. If enough keys are deleted from a database that shrinking the underlying file is desirable, you should create a new database and insert the records from the old one into it.
So chances are that DB doesn't blank the items, but just removes the references.

If deleting the hash doesn't work, did you try the object interface? You can do $db = tie %hash .... and later $db->db_del or something similar.

Hope this helps,

Jeroen
"We are not alone"(FZ)

  • Comment on Re: tied hashed and deleting keys and their valeus

Replies are listed 'Best First'.
Re: Re: tied hashed and deleting keys and their valeus
by skazat (Chaplain) on Jan 31, 2001 at 15:09 UTC

    This means that the Btree and Hash databases are grow-only

    wow, that's. crazy. what a bad system! I'll try the object interface... does that work with the AnyDB_File as well?

    what possesed someone to make a db package like that? I guess its a tradeoff for being able to hold large amounts of info in the first place (grumble grumble)

     

    -justin simoni
    !skazat!

[reply]
      Well, you can imagine that whenever you have a 2Gigabyte file, it takes really a lot of time to shift the whole thing let's say 10 bytes. If the database is occupied with that every delete for about 15 minutes, the user isn't happy.

      If you really want to save space, the copy isn't a really bad option.

      Jeroen
      "We are not alone"(FZ)

[reply]
      This is a relatively known and generally widely accepted drawback to using DB files. As another poster mentions, the overhead involved in re-building the DB file after the deletion of a row within it would make using the DB file horribly slow and expensive. Space is re-used where it can. In other words if you come back later and insert a new row, it will try to re-use some of the space already allocated (but 'deleted'), but it's not going to make an effort to shift everything else around to accomodate. This is precisely the same problem that leads to filesystem fragmentation.

      If you want efficient data storage, consider using a real database instead.

[reply]
      Well, the speed vs. space trade off is the most common optimization there is. In this case it is a perfectly fine tradeoff that they made. How often do you think it is that DBs shrink significantly?

      --
      $you = new YOU;
      honk() if $you->love(perl)

[reply]

        I use the DB File to save mailings from a lightweight Mailing List Manager I develop. The only time something needs to be removed is when the administrator deletes an email message that saved in the DB FIle archive. The keys are created using the date, so no 2 keys are ever used twice. If the removed entries' space is reused later, that's perfectly fine. My test archive was about 3.5 megs, about 100 messages worth.

        I still have the problem of entries not being removed at all. Anyone else have this?

         

        -justin simoni
        !skazat!

[reply]

In Section Seekers of Perl Wisdom