[Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 03:23:22PM +0200, Jesus Cea wrote:
-> -----BEGIN PGP SIGNED MESSAGE-----
-> Hash: SHA1
-> 
-> Brett Cannon wrote:
-> >> Related but tangential question that we were discussing on the pygr[0]
-> >> mailing list -- what is the "official" word on a scalable object store
-> >> in Python?  We've been using bsddb, but is there an alternative?  And
-> >> what if bsddb is removed?
-> > 
-> > Beyond shelve there are no official plans to add a specific object store.
-> 
-> If you are storing million of objects, you'd better use a transactional
-> storage, able to survive diskfulls or code/computer crashes.

We're using a write-once-read-many pattern of access, and it is simply a
cache of a separate file (that remains around), so no, we don't better
use a transactional storage :).

-> I will maintain "bsddb" as a separate (downloadable via PYPI) package
-> whatever the fate of bsddb in Python stardard library be. So bsddb is a
-> pretty safe bet, even if you need to install it separately.

Since I/we want to distribute pygr to end-users, this is really not a
pleasant prospect.  Also often the installation of Python itself goes
much more smoothly than the installation of separately compiled binary
packages, for all the obvious reasons (compiler/OS versions, lib
versions, etc. etc.)

-> 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.

I agree.  I like bsddb for just this reason and I'd like to continue
being able to use it!  I think that there are many reasons why having
such a thing in the stdlib is really useful and I also think it's worth
exploring the ramifications of taking it out...

--t
-- 
C. Titus Brown, ctb at msu.edu