Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Conflicted writes aren't evicting obsolete view rows #65

Closed
jchris opened this Issue · 1 comment

2 participants

@jchris
Owner

I can reproduce this by running two instances of the Syncpoint iOS-Demo pointed at a cloud Couch.

First create a grocery list item on one phone, and wait for it to show up at a remote phone, then put the remote phone in Airplane Mode. Then:

1) on the Airplane Mode phone, click the checkbox once.
2) on the other phone (simulator maybe) click the checkbox twice.

Take the phone out of Airplane Mode.

In a few seconds you should see two copies of the document on both phones.

If you look in the .touchdb file, you see more than one rev for the document, lingering in the view rows. It is also still marked as current in the revs table.

@snej
Owner

This is nasty! I think the TDView indexing algorithm only removes emitted rows when it finds a deleted revision, but not when it finds a revision that's been hidden by a conflict (i.e. another revision of the same doc was added that 'won' the conflict.)
This may be tricky to fix; but I won't be sure until I look at the code again.

@snej snej closed this issue from a commit
@snej snej Fixes for indexing documents in conflict
There were a couple of problems in the situation where you're indexing a new revision that conflicts with an already-indexed revision.
(a) If the new revision is the 'winner', the previously-emitted view rows for the earlier revision need to be removed, because that revision's not visible anymore. Otherwise you can have two revs of the same document showing up in the index.
(b) If the new revision is the 'loser', the *older* revision needs to be indexed again, with the new emitted rows *replacing* the old ones. This is because the map function needs to see the new _conflicts array in the doc properties.

This fixes #65, which reported case (a). Case (b) I noticed on my own and fixed at the same time.
45fdce9
@snej snej closed this in 45fdce9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.