On Thu, Sep 4, 2008 at 10:03 AM, <skip@pobox.com> wrote:
Compared to sqlite, you don't need to know SQL, you can finetuning (for example, using ACI instead of ACID, deciding store by store), and you can do replication and distributed transactions (useful, for example, if your storage is bigger than a single machine capacity, like my case). If you combine Berkeley DB with Durus, for example, all of this is abstracted and you simply use "regular" python objects.
Titus> I agree. I like bsddb for just this reason and I'd like to Titus> continue being able to use it! I think that there are many Titus> reasons why having such a thing in the stdlib is really useful Titus> and I also think it's worth exploring the ramifications of taking Titus> it out...
I suggested in another message (perhaps on another thread) that maybe a dbm.sqlite module would be worth having. It would have a dict-ish API like the other dict-on-disk modules but use the sqlite module to read (SELECT) and write (INSERT and UPDATE) key/value pairs from the underlying database.
I offered to write one of these a couple months ago as an option for some users who would otherwise think to use bsddb, dbm, or anydbm. Few people saw that anything like that would be useful, detractors stating that the expansive options available in bsddb (most of which I didn't realize existed) made it effectively irreplaceable to the vast majority of people who actually use bsddb for anything nontrivial. There wasn't even feigned interest in those use-cases involving "trivial" disk-persistent dictionaries (of which 100% of my uses have involved over the last 10 years). - Josiah