[Zope] Re: _p_resolveConflict not called on conflict
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
More information about the Zope