Sent from my iPad
On May 18, 2013, at 1:56 AM, "Randall Leeds" <[email protected]> wrote: > On Fri, May 17, 2013 at 12:12 PM, Randall Leeds <[email protected]> > wrote: >> On Fri, May 17, 2013 at 11:57 AM, Robert Newson <[email protected]> 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.
smime.p7s
Description: S/MIME cryptographic signature
