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 > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
