couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Deleted and Replacement documents and VDU behavior
Date Sat, 18 May 2013 08:55:41 GMT
On Fri, May 17, 2013 at 12:12 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Fri, May 17, 2013 at 11:57 AM, Robert Newson <rnewson@apache.org> 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.

Mime
View raw message