durusmail: durus-users: Alternative storage WAS A newcomer and BerkeleyDB
A newcomer and BerkeleyDB
2005-12-15
2005-12-15
2005-12-15
2005-12-15
Alternative storage WAS A newcomer and BerkeleyDB
2005-12-15
Re: Alternative storage WAS A newcomer and BerkeleyDB
2005-12-15
Re: Alternative storage WAS A newcomer and BerkeleyDB
2005-12-15
Re: Alternative storage WAS A newcomer and BerkeleyDB
2005-12-15
Re: Alternative storage WAS A newcomer and BerkeleyDB
2005-12-16
2005-12-16
2005-12-16
Re: A newcomer and BerkeleyDB
2005-12-16
2005-12-15
2005-12-16
2005-12-16
2005-12-16
2005-12-16
2005-12-16
Alternative storage WAS A newcomer and BerkeleyDB
Peter Fein
2005-12-15
Folks said:
>> 

I used durus (2.0 betas, IIRC) as the primary data storage for a
prototype app (we've sinced move to postgres).

Many of our apps now use a "pickle on disk" approach for managing their
storage needs, passing data, etc.. It's crude & sometimes ugly, but
effective.  The benefit is that each pickle represents a complete, high
level standalone object. Fortunately, we're able to generate unique
filenames. Basically, we avoid the Durus single-file object store with
offsets approach by using separate files, in the process giving up the
ability to have objects relate across files.  Make sense?

The upshot is, this is sufficient for our problem. It'd be nice to use
the durus interface with this sort of backend...  A SMOP, I'm sure. ;)
reply