[Zope] Re: _p_resolveConflict not called on conflict

Chris Withers chris at simplistix.co.uk
Fri Aug 10 03:20:44 EDT 2007

Martijn Pieters wrote:
> On 8/9/07, Chris Withers <chris at simplistix.co.uk> wrote:
>> Indeed, but it's still a storage, there's no reason for it not to do
>> conflict resolution itself. I thought it did ;-)
> It's not a storage at all.

Really? I'm pretty sure it implements the relevent storage interfaces 
otherwise it wouldn't slot in the place of FileStorage...

> It's a stub for the actual storage which
> lives in the server.

That stub *could* do conflict resolution for client-side connects, I 
thought it did, but it looks like it doesn't.

>> Wouldn't it be beneficial if it *did* do conflict resolution?
>> (afterall, if the conflict can be resolved on the client, why go all the
>> way to the storage server to do the conflict resolution there?)
> "Wouldn't it be nice" is a big difference from "I thought it did" :-)

Yes well, I hoped it was the latter, but it looks like it's the former :-(

> It would be nice, but I am not sure it can do it. Conflicts are
> detected at the storage level, and as that level lives in the ZEO
> server, that's where resolution has to take place. Propagating the
> conflict back to the client because it *may* do conflict resolution
> would be less efficient still, as in most cases there is no conflict
> resolution available.

I'm only talking about having ClientStorage resolve conflict between the 
threads of that client, not about propagating conflicts between clients, 
that *would* be nuts ;-)



Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk

More information about the Zope mailing list