0

In my android app i have setup pull replication with sync_gateway.

Due to the specific app's logic, whenever a conflict is detected, i need to keep just the document revision replicated from the server.

I'm able to define which conflicting version comes from the replication (server) and which one comes from a local modification (mobile app).

If i create tombstones and a new revision with the data from the replication revision (which is the suggested approach), i will have continuos conflicts because the local revision id will be always different from the one on the server (any new revision used to elect the currentRevision will have a different id).

My best solution would be to keep just the server revision as the current revision and discard any other.

How can i do this?

Is it possible to purge revisions? Or is it possibile to create an object that contains just the server revision so that after conflict resolution any other pull without conflict will just update my document? I need a behaviour similar to an override.

Giorgio Andretti
  • 198
  • 1
  • 15

2 Answers2

1

It depends what the outcome of the conflict resolution should be:

  • Merging document properties: in this case you need to create a new revision whose properties are from each conflicting revision and then delete all the revisions.

  • Cleaning up conflicting revisions: in this case you can delete all the revisions except the one you'd like to keep. It may be that the revision you want to keep is not the current revision but removing all other revisions will make it become the current revision.

See the TodoLite-Android conflict resolution example (https://github.com/couchbaselabs/ToDoLite-Android/blob/bcd87faa4c68a7cee075468b08da55c8041830a7/ToDoLite/src/main/java/com/couchbase/todolite/ListConflicts.java#L51-L81).

jamiltz
  • 1,144
  • 8
  • 15
  • Deleting a revision will create a new revision that may become the winning revision if its revision id becomes greater than any other. As an example: server rev 1-111 gets replicated to mobile. Mobile adds rev 2-321 and server rev 2-222 so mobile rev 2-321 is the winner. I discard the mobile rev because i have to keep the server revs as winners so i create a new deletion rev: 3-111. The deletion revision becomes the winner so i have to create a new rev based on the server rev's content but since that moment the id will be different with the one of the server creating conflicts on any pull. – Giorgio Andretti Mar 21 '16 at 08:13
  • Can't you just delete rev 2-321 which would make rev 2-222 the current revision? – jamiltz Mar 21 '16 at 19:20
  • That is exactly the problem i'm facing: how can i delete a local revision without creating a new one that is set to deletion? For what i've understood, revisions can't be deleted. Maybe i didn't understood how, but if you can provide me a simple code snippet i will be grateful! – Giorgio Andretti Mar 22 '16 at 09:28
  • Ohh right because deleting rev 2-321 will create 3-... You could purge immediately rev 2-321 and you would need to do that on every client that has both 2-* revisions. – jamiltz Mar 22 '16 at 12:18
  • I solved the question and posted the solution. I was wrong and couldn't understand why i was confused. I will accept your solution as it is correct, thank you (but i found i was tricking you ;) ) – Giorgio Andretti Mar 22 '16 at 17:03
1

I solved the question but the problem is that i was making confusion.

So this is what i learned thanks to the replies to my post here:

  • Deleted revisions cannot win over non-deleted revisions, even if their revision number is higher
  • When you have conflicts it means that there are open branches in the revision tree (and with open branch i mean a revision branch that doesn't have a tombstone at its end)
  • If you don't have conflicts it means that you may have different revision branches but all except one have a tombstone revision at their end. The one without tombstone is the current (winning) revision
  • If all the branches have a tombstone that means you have deleted the document
  • When an open branch that represents the current (winning) revision gets closed with a tombstone revision, another open branch among the ones still opened (conflicting branches) is elected as current (winning) revision. If there are no other open branches then the document is considered deleted
  • When an open branch that doesn't represents the current (winning) revision (and thus generates conflicts) gets closed with a tombstone revision, nothing changes except that that branch won't create conflicts anymore
Giorgio Andretti
  • 198
  • 1
  • 15