On Mar 9, 2010, at 10:11 AM, Jesus Cea wrote:

> On 03/09/2010 12:30 PM, Binger David wrote:
>> This sounds like a capability that would be useful to us, too.

To be clear, the capability I mean is the capability to execute long updates
on huge databases without stopping the service during the update.
I'd like to have this capability with very little or no change to the
Durus storage code, and that seems possible.

>
> Good!.
>
>> I'm not sure about the details.  Why use separate files for all
>> of the pickles?  I think we could use the existing FileStorage code
>> for this temporary store.
>
> Well, it is just how my current patch works. Dirty and ugly, but it
> works. It is easy and allows easy replication to a remote site, for
> instance.
>
>> It seems like the essential function required is a command that
>> a client sends to the server to tell the server to start a transaction log.
>> Is that right?
>
> I use stacked backend storages, as I said. Not sure if allowing a client
> to activate it on demand is appropiate.

I'm not sure why.  Clients do anything else.

>
> Using stacked storages allows to be more flexible, because the stacked
> component can do anything with the transactions. They can be stored on
> disk, or they can be sent to a remote site for replication. Or simply
> extract statistics. Or deploy the readonly+readwrite backends I talked
> about in the last message.
>
> Not sure a client can demand this kind of things on the fly, using the
> durus wire protocol. Seems more a thing you should do instancing the
> right backends in the server process.
>


Your interest in backend flexibility is reasonable, but I am not so interested
in that.  I don't see any obstacles to using clients for replication or running
statistics, no matter what backend you use.