couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <>
Subject Re: Deleted and Replacement documents and VDU behavior
Date Sat, 18 May 2013 15:04:30 GMT

Sent from my iPad

On May 18, 2013, at 1:56 AM, "Randall Leeds" <> wrote:

> On Fri, May 17, 2013 at 12:12 PM, Randall Leeds <> wrote:
>> On Fri, May 17, 2013 at 11:57 AM, Robert Newson <> wrote:
>>> 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. 
View raw message