History for DualCacheConflictResolution

??changed:
-
Purpose: To take advantage of the power of Connection Caches of objects to assist in resolving DB Conflicts at commit time.

Assumption: A simple/useful/possible way exists to identify the "containing object" of a Persistent collection.  This could be as simple as adding a registerContainer(obj) method to PersistentMapping to take advantage of this resolution mechanism.

Proposal: Add a "_p_resolveConflict" method that is given an object reference to a new Connection cache object that represents this object in the ZODB that has already been committed.  


_p_resolveConflict(self, savedObject) -- 
   Modify self, and object navigable from self, to resolve differences with savedObject in DB or throw exception.

   Arguments:

   savedObject -- An object from a new Connection Cache that represents this same object as                                   stored in the database. This object reflects
		 changes made by a transaction that committed before the current
		 transaction. 

  	         The method is permitted to modify this value, and any navigable from it - all object from this Cache will be thrown away after this commit activity.

The "_p_resolveConflict" method has the additional ability to modify all objects that are navigable from "self", and to use "savedObject" to navigate to the current object, not just dictionary of state, in the DB.

The "_p_resoveConflict" method will be called for every conflicted version without ordering.  It is up to the resolution code to make sure that a conflict is not "corrected" twice by navigating to and manipulating an object in the currently committing transaction cache.