Wiki: Sync 2.0 conflict resolution logic

Tags: #<Tag:0x00007fdb1b50dae0> #<Tag:0x00007fdb1b50d810> #<Tag:0x00007fdb1b50d108>

(Brandon Istenes) #1

Is it no longer possible to leave comments on the Wiki? This seems like a weird thing to start a Talk thread about, and there’s no “Wiki” or “Documentation” category on Talk…

Anyway, on the Sync 2.0 wiki conflict resolution page there’s a part that reads

  • #C : a hash code of the child instance object
  • #P : a hash code of the parent instance object
  • #lastP : a last saved hash code of the parent instance object.

The conflict is detected when #lastP != NULL && ((#lastP != #P) || (#lastP != #C)).

Should that read #lastP != NULL && (#lastP != #P && #lastP != #C) (or, equivalently, #lastP != NULL && (!(#lastP == #P || #lastP == #C))? As it is, it seems to read “a conflict is detected if either the parent or the child disagree with the previous parent” rather than “a conflict is detected if both the parent and the child disagree with the previous parent,” which is what I would expect.

(Daniel Kayiwa) #2

Is this of help? How do i add a wiki comment?

cc @SolDevelo

(Brandon Istenes) #3

Ah, interesting. Thanks Daniel.

Ping @alalo

(Arkadiusz Lalo) #4

Hi @bistenes,

The lastP store the last (after each synchronization action) hash code of each object. It is used because we need to know where the object was changed (on parent/on child/on both). Note that we don’t store the history for each object. Now if you know that only the parent’s representation was changed you know that this is the newest representation.

If we will use only parent’s and child’s hash code then the conflict will be always detected.

If the detection conflict mechanism proposed by us didn’t meet your expectation feel free to add alternative mechanism (and make sure that the user can choose which mechanism will be used via a setting or Sync configuration).

cc: @kmadej

(Brandon Istenes) #5

I’m not totally sure I follow. Let’s break this down a bit. There are four possible scenarios.

  1. Neither the parent nor child has changed. #lastP == #P && #lastP == #C
  2. Only the parent has changed. #lastP != P && #lastP == #C
  3. Only the child has changed. #lastP == P && #lastP != #C
  4. Both the parent and the child have changed. #lastP != P && #lastP != #C

The expression on the wiki, (#lastP != #P) || (#lastP != #C) will evaluate as true in scenarios 2, 3, and 4.

However, when you say

Now if you know that only the parent’s representation was changed you know that this is the newest representation.

I take that to mean that case (2) should not be a conflict.

(Arkadiusz Lalo) #6

Hi @bistenes ,

I took a look again and you are right.

On this stage we want to know if any object was changed (so the expression could be simplified and check only differences between #P and #C).

The more specific information about which exactly objects was changed is useful when we try to resolve the conflict. When we, for instance, know that only child object was changed then we can choose this representation as newest and resolve the conflict automatically. Of course if we will know that both parent and child objects were changed then we need to resolve the conflict manually (or if possible we can use the date of update). I hope now it will be more clear.

For sure the expression (when we try to detect the conflict/changes) could be simplified. I’ve created the ticket for changing that in Project Backlog ( Thank you for your feedback.

cc: @kmadej

(Brandon Istenes) #7

I certainly can’t say authoritatively, but I suspect that it can’t be simplified further than

#lastP != null && #lastP != #P && #lastP != #C

which is equivalent by DeMorgan’s law to

#lastP != null && !(#lastP == #P || #lastP == #C)

if that’s how you prefer to look at it.

I’ve updated the Wiki to at least be correct, maybe it can be improved upon later from that point :slight_smile:

Thanks for helping clarify!