Dennis Allison wrote at 2005-12-14 12:58 -0800:
>_p_resolveConflict(self, oldState, savedState, newState)
>returns the state of the object after resolving different changes. The
> oldState -- state of the object at the beginning of the current
> transaction (mutable)
> savedState -- state currently stored in the database. This state
> was written after oldState and reflect changes made
> by a transaction that committed before the current
> transaction (immutable)
> newState -- state after changes made by the current transaction
>It seems to me that we can do much better for sessions because we know a
>bit about the semantics of sessions. A session object is a
>dictionary-like object mapping key-value pairs. Adding or deleting keys
>or changing the value associated with a key are independent operations and
>do not conflict unless the keys are duplicated in both the transactions.
>Any conflict resolution mechanism needs to be able to manage multiple keys
>independently since the session object is modified as a unit. In
>addition, new keys may be added and old keys deleted; any conflict
>resolution mechanism at the key level needs to be comprehend those
>A more session-friendly conflict resolution might use:
> 1. if any of the states are invalid (that is, has a key '_invalid')
> return the invalid state.
> 2. if any any of the states attributes ['token','id','_created']
> differ then there is a conflict, raise the conflict exception.
> 3. order the newState and savedState by modification time (or if that
> cannot be computed, by access time).
"newState" is always after "savedState" ("saveState" represents
a formerly committed state, "newState" the current state the
commit of which failed).
> 4. any key appearing in oldState's dictionary but not appearing in
> both savedState and newState should be removed from all. This
> corresponds to a key-value pair being deleted in one of the
> transactions. Insertions will be managed automatically by
> the updates.
That looks doubtful: It means, if any of the transactions deletes
the key, then it should be removed. You favour deletion a bit.
> 5. beginning with the oldest, update oldState dictionary of key-value
> pairs using the dictionary part of newState and savedState. Return
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -