James Hamilton makes a recommendation similar to what Doug is asking about in this great paper: http://www.mvdirona.com/jrh/talksAndPapers/JamesRH_Lisa.pdf
"Never delete anything. Just mark it deleted.... The ability to recover the data can make the difference between a highly embarrassing issue or a minor, barely noticeable glitch." Hamilton also recommends doing this at the application (service) level, echoing Kevin's recommendation: "Handle failures and correct errors at the service level where the full execution context is available rather than in lower software levels. For example, build redundancy into the service rather than depending upon recovery at the lower software layer." One final comment here: an HTTP 410 response denotes a notion of "permanently gone" rather than a soft delete. In fact, the HTTP/1.1 RFC explicitly says that you want to use a 404 for a soft delete: "10.4.11 410 Gone. The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent.... If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead." http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.11 Jon -----Original Message----- From: riak-users-boun...@lists.basho.com [mailto:riak-users-boun...@lists.basho.com] On Behalf Of Kevin Smith Sent: Thursday, April 15, 2010 7:10 AM To: Doug Tangren Cc: riak-users@lists.basho.com Subject: Re: http 410 deletes and document revival That is an interesting use case. The biggest issue I see with it, though, is the implication of a permissions system (x-riak-perm-delete) which doesn't exist. All is not sadness, though. You can achieve something very close to this with bucket pre/post commit hooks and modifications to your application logic. Pre/post commit hooks will be in the very next release of Riak. For example, let's say you've set a pre-commit hook function on the bucket "important" which looks for the custom header "x-riak-myapp-perm-delete". If this header is set to false, then the pre-commit hook makes a copy of the about-to-be deleted object and stores it in a bucket named important_deleted and then performs the delete. If the header is set to true, then the hook allows the delete without making a backup copy. Now the boss looks for the object and gets a 404. Your application knows to check for a backup copy in important_deleted. Your application finds the backup copy and restores it to its rightful place in important. I need to move the docs for pre/post commit hooks over to the wiki but a complete write up exists in the Riak bug tracker here: http://issues.basho.com/show_bug.cgi?id=34 --Kevin On Apr 15, 2010, at 12:20 AM, Doug Tangren wrote: > I don' know if this would be worth adding to the http interface or not but might it be useful to have a `soft delete` feature where the http interface returns a 410 (Gone) rather than a 404 (Not Found) status code after a document has been deleted. Perhaps as an audit trail or even a rollback feature. > > A use case might be > > # currently > > boss > > PUT http://host.com/riak/important/someImportantDocumentA { ... } -> docA > PUT http://host.com/riak/important/someImportantDocumentB { ... } -> docB > > intern > > DELETE http://host.com/riak/important/someImportantDocumentA // "Whoops! I think I might have deleted the wrong document! Hope the boss doesn't find out." > > boss > > GET http://host.com/riak/important/someImportantDocumentA // 404 "wtf!? Where did my TPS report go?" > > boss calls up intern --censored-- > > # a proposal > > boss > > PUT http://host.com/riak/important/someImportantDocumentA { ... } -> docA > PUT http://host.com/riak/important/someImportantDocumentB { ... } -> docB > > intern > > DELETE http://host.com/riak/important/someImportantDocumentA (with new header x-riak-perm-delete=false) // "Whoops! I think I might have deleted the wrong document! Hope the boss doesn't find out" > > boss > > GET http://host.com/riak/important/someImportantDocumentA // 410 "silly intern, let's see what else he did" > > GET http://host.com/riak/important { "props": { ..., "deleted_keys":["someImportantDocumentA"] ] } } > > PUT http://host.com/riak/important/someImportantDocumentA (with new header x-riak-revive=true) > > GET http://host.com/riak/important/someImportantDocumentA // 200, "heh, glad I set my `important` bucket's `perm_delete` property to false" > > GET http://host.com/riak/important { "props": { ..., "deleted_keys":[], "perm_delete":false ] } } > > boss calls up intern and says not to worry and makes sure intern gets TSP report, mmm k. > > > This is essentially a 2 new features. > * a deletion audit trail with a bucket's deleted keys ( "deleted_keys":["foo","bar"] ) and 410 (gone) responses (of course this would probably be turned off by default) > * per document rollback/revive feature that allows up to undo/undelete previously soft deleted documents > > What does everyone think? Would this be useful? > > > > > > > -Doug Tangren > http://lessis.me > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
