durusmail: durus-users: Re: 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
Re: Alternative storage WAS A newcomer and BerkeleyDB
Peter Fein
2005-12-15
Jesus Cea wrote:
> Peter Fein wrote:
>
>>>The benefit is that each pickle represents a complete, high
>>>level standalone object. Fortunately, we're able to generate unique
>>>filenames.
>
>
> That approach is simple but if your machine crashes, you are in big trouble.
>
> Suppose this case:
>
> 1. You update several objects in a transaction.
> 2. Your code starts to dump the new objects to disk. Hopefully you save
> the objects using other names, "fsync", and then rename the objects.
> You'd better do :-p
> 3. Your machine crashes, power failure, whatever.
> 4. Now some of your changes are lost. I can ever have a dangled
> reference to unexistent objects.

I don't care.  I should have been clearer about this, but along with the
 lack of references to other pickles, we don't care about consistency
across pickles.  Basically, writing each object to disk is effectively
an independent transaction.

>>>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. ;)
>
>
> Ideally the backend interface should be documented, to easily use
> multiple "plug-ins" :-p

Sure! ;)  I think it is, actually.

reply