Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Resurrected doc rev should be child of tombstone #207

Closed
snej opened this Issue · 0 comments

1 participant

@snej
Owner

Damien just schooled me on what should happen if a doc is deleted and then re-created, i.e. after

PUT /db/doc
DELETE /db/doc
PUT /db/doc

Currently in TouchDB the last revision that resurrects the document has no parent and a generation of 1, just like the first revision. This makes some sense, but leads to the rather nasty situation of #205. It also complicates the winning-revision algorithm. I think it could also lead to weird conflicts in some scenarios.

What should be happening — what CouchDB does — is that the resurrected revision should be a child of the tombstone. Its rev ID will start with "3-". This ensures it has a unique rev ID, avoiding #205, and also ties it into the same timeline that the deletion occurred on.

@snej snej was assigned
@snej snej closed this issue from a commit
@snej snej Real fix for 'resurrection' of deleted doc
A PUT, DELETE, PUT sequence should result in a rev with generation 3
that's a child of the tombstone revision.
This fixes #207 and is the real fix for #205.
5e05a8a
@snej snej closed this in 5e05a8a
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.