[Cosmo-dev] Interesting idea to avoid EIM conflicts

[Jeffrey Harris]

Hi Morgen,

Morgen Sagen wrote:
> There are situations where you want to share data but don't want
> "simultaneous" changes to the data to be considered a conflict.  One
> example is the "lastModifiedBy" EIM field.  If two people change an item
> and sync, you don't want to show the user that there was a conflict on
> the "last modified by" field, you just want the most recent change to
> automatically "win".  Phillip suggested a neat way to model this in EIM
> which avoids conflicts altogether-- define a new record type for "last
> modified by" which contains three fields: item uuid, userid, and
> timestamp -- and have all three of those fields be record keys. To
> represent that a change has been made to lastModifiedBy, you create a
> new record and delete the old one.  Since all three fields of that
> record are keys, you can never conflict.  When processing inbound
> records of this type, you skip any "out of date" ones (those whose
> timestamp field are earlier than the one last processed.  In fact --
> this way we also get a "last modified time" field for free.
> 
> Would this be hard to implement in Cosmo?
> 
> By the way, we could also handle triageStatusChanged this way.

How are you thinking this would work when paired with a real conflict?

If, say, on a shared item Arthur changes the title, then Bea changes the
title 5 minutes later, but Bea syncs first, and Arthur gets a conflict.

It seems like lastModifiedBy should be part of that conflict, not
separate from it, because if Arthur rejects Bea's change, Arthur's
really the last one who modified the item.

Maybe when you reject someone else's change we always set lastModifiedBy
to you (that seems right, now that I think about it).

In the interim state where we're displaying the item with a conflict, it
seems like Arthur's Chandler ought to say the item was changed by
Arthur, but has conflicts from Bea.

Sincerely,
Jeffrey