couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <jim....@sri.com>
Subject Re: immutable _id's
Date Wed, 21 Nov 2012 19:08:59 GMT
Ok, that's what I'm discovering.

Well here's my thinking… I assuming I can use a VDU to forbid a newDoc._delete = true and
validate against a oldDoc.tombstone to prevent reuse(I'm assuming that VDU get's executed
regardless if the delete is initiated via DELETE/POST verbs).
Then use the update handler to manage construction of the tombstone doc.

I think for our purposes I won't have to deal with the reverse proxy (i've found that really
tricky to work right anyways, i.e. inbound DELETE is trivial, but delete via POST is tricky,
because you can query multi-keys using POST too… and some updates are okay in my case).
  As long as the VDU will let me forbid newDoc._delete, I should be able to not care about
blocking access.

Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t.	@nsomnac

On Nov 21, 2012, at 10:46 AM, Dave Cottlehuber <dch@jsonified.com>
 wrote:

> On 21 November 2012 16:12, Jim Klo <jim.klo@sri.com> wrote:
>> Okay, say I did this. In the validate_doc_update, if someone tries to delete a doc,
would I be able to modify the new doc and remove the _deleted field and just empty the doc
myself - basically creating my own tombstone?
>> 
>> - Jim
> 
> No, VDUs are a pass/throw result only, no modification allowed. You
> might be able to fake this by sending your DELETEs to a custom update
> handler, and some jigery pokery to prevent normal document DELETEs
> being accepted within the VDU apart from via your update handler; not
> sure if that's possible though so your fallback would be blocking
> inbound DELETEs using a reverse proxy.
> 
> A+
> Dave


Mime
View raw message