couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: Deleted and Replacement documents and VDU behavior
Date Sat, 18 May 2013 21:23:14 GMT
On Sat, May 18, 2013 at 1:57 PM, Jim Klo <> wrote:
> Sent from my iPhone
> On May 18, 2013, at 1:39 PM, "Randall Leeds" <> wrote:
>> On Sat, May 18, 2013 at 8:04 AM, Jim Klo <> wrote:
>>> Sent from my iPad
>>> On May 18, 2013, at 1:56 AM, "Randall Leeds" <>
>>>> On Fri, May 17, 2013 at 12:12 PM, Randall Leeds <>
>>>>> On Fri, May 17, 2013 at 11:57 AM, Robert Newson <>
>>>>>> oldDoc is null in this case. That matches the case that the doc is
>>>>>> brand new and is surely deliberate? I asked him to post it this here
>>>>>> because I do understand the benefits of it being otherwise and wanted
>>>>>> to see this conversation.
>>>>>> My position is that deleting a document should free that id for any
>>>>>> future use, which is exactly what Jim does not want.
>>>>>> I'd like to hear from folks that might have a memory of when this
>>>>>> particular semantic was decided. I think it could arguably have gone
>>>>>> the other way.
>>>>> I know we have a clause for revivification for an update without a rev
>>>>> to a deleted doc.
>>>>> This proposed alternative behavior is attractive to me and if my
>>>>> armchair spelunking is correct, it's actually pretty trivial. It seems
>>>>> to me like we could even make a minor breaking change for 1.4 where
>>>>> the old doc is always passed to VDU handlers, even if it's a
>>>>> tombstone. Migration would mean updating VDU handlers to consider
>>>>> oldDoc._deleted. I think many are probably using VDUs for validating
>>>>> the new doc anyway, and would ignore the second parameter.
>>>>> The default semantics could stay the same, but if we just passed the
>>>>> tombstone to VDU handlers it would be customizable in exactly the way
>>>>> Jim wants. Sounds exactly like the sort of thing VDU is for.
>>>> I just realized that it's not clear which revision should be provided
>>>> when attempting to revive a deleted doc, since there may have been
>>>> several revision histories which ended in deletes and there is no
>>>> previous rev specified.
>>> I think in this case only I'd expect only the deleted 'tombstone' doc to be handed.
I'm not sure what rev that falls under.
>> I'm saying that due to replication conflicts it may be that there are
>> multiple choices.
> Thanks Randall,
> Educate me please. How does this differ from how it works now on an update where the
rev is provided? Assuming the doc has been deleted, the rev of the tombstone is the only thing
I would think you'd have to be concerned.  How would a conflict occur? Are you thinking that
the conflict is when replicating from multiple sources - I'd think you'd have this race condition
either way in a M-M scenario.

I don't believe it's necessary to specify a rev when creating a
document that has previously been deleted. It "comes back to life"
without the client needing to specify which revision was the deleted

In a typical update scenario, the previous revision is provided with
the request and if it doesn't match what is stored then a conflict is

However, with M-M replication scenarios, it's possible to end up with
conflicts. If a document has more than one live, conflicting revision,
and then they are all deleted, it's unclear to me which revision
should be sent as the "old doc" to the VDU if a create request for
that ID occurs later.

One possibility would be to take the "winning" rev. Usually, a
document with a branching revision tree returns a winning rev as the
response to a GET, but deleted leaf revisions are ignored. The same
precedence could work though, for determining which old doc to pass to
the VDU, by including deleted revisions when there is no *non*-deleted
leaf revision.

View raw message