[ZODB-Dev] Synchronizing Mirror Sites

[Norfleet, Sheppard S.]

If an object is deleted, and a change comes for it, the change is discarded
and reported as a conflict.  Since only the owner can delete the object,
that situation needs to be worked out between the person sending the change
and the owner.

Also, if a change comes in and the object is locked (using CMFStaging), the
change is discarded and reported as a conflict.

Since only the owner can delete the object, it doesnt matter if anyone else
wants to change it as the owner is the final authority on the disposition of
the object.  

So, if the object is deleted and recreated, the change will attempt to go to
the deleted item, but will fail as a conflict, and the newly created item
will remain unchanged.  

These are all acceptable outcomes...for my needs

One thing I have to make sure is that the undo capability is disabled in the
CMF, cause I havn't a clue how to handle that situation...

Regards 

Shep



-----Original Message-----
From: Dieter Maurer [mailto:dieter at handshake.de]
Sent: Thursday, July 24, 2003 2:45 PM
To: Norfleet, Sheppard S.
Cc: 'Shane Hathaway'; 'zodb-dev at zope.org'
Subject: RE: [ZODB-Dev] Synchronizing Mirror Sites


Norfleet, Sheppard S. wrote at 2003-7-24 07:21 -0700:
 > ...
 > Every time an object is modified in the CMF, I will send the object to a
 > replicator product, where it will be wrapped with metadata, pickled, and
 > stored.  So I need to modify all the CMF form processing scripts like
 > document_edit.py.  
 > 
 > The replicator product will routinely (via outside cron job) check for
 > updates.  On a per object basis, it should simply be a matter of
replacing
 > the old object with the new object, right?
 > 
 > After some thought, I realized that I dont really have to have a merge
 > capability.

Unless the *same* object is modified at different locations.

Other interesting situations:

  One side modifies, the other deletes.

  One side modifies, the other deletes then recreates.


Dieter