Please help to promote: On Hacker News /newest for the next 30 mins or so
http://www.reddit.com/r/CouchDB/comments/22i9pr/the_little_things1_do_not_delete/ http://www.reddit.com/r/nosql/comments/22i9qr/the_little_things1_do_not_delete_couchdb/ https://lobste.rs/s/royp74/the_little_things_1_do_not_delete https://twitter.com/CouchDB/status/453489805452910592 https://plus.google.com/u/1/109226482722655790973/posts/4C4P2i66SyU https://plus.google.com/u/1/109226482722655790973/posts/fnVhZRPUwJT https://www.facebook.com/permalink.php?story_fbid=525998800765682&id=507603582605204&stream_ref=10 Circulating to user@ and dev@ On 8 April 2014 12:56, Jan Lehnardt <[email protected]> wrote: > Published: https://blogs.apache.org/couchdb/entry/the_little_things_1_do > > Thanks for the nice feedback everybody! :) > > On 08 Apr 2014, at 12:54 , Noah Slater <[email protected]> wrote: > >> This is excellent Jan. Please post it. >> >> To Jan and others: ping me once you post something. I'm quite good at >> online promotion. >> >> On 7 April 2014 22:16, Jan Lehnardt <[email protected]> wrote: >>> Hey all >>> >>> I have an idea for a new blog series: >>> >>> Category: The Little Things >>> >>> Theme: Explaining some of the little features we put into CouchDB that make >>> people's lives easier. >>> >>> First draft of the first article: >>> https://blogs.apache.org/roller-ui/authoring/preview/couchdb/?previewEntry=the_little_things_1_do >>> (pasted below for those of you who don't have a blog account) >>> >>> What do you think? :) >>> >>> I'm imagining to solicit more articles from the developers on dev@ as new >>> things arrive in the code-base. And we can take inspirations from user@ and >>> IRC when we explain a certain behaviour to a user and what the reasoning >>> behind that is. >>> >>> I think this is a good way to get people to learn and talk about a number >>> of clever things we are doing outside of the regular channels. >>> >>> Best >>> Jan >>> >>> * * * >>> >>> <p>CouchDB takes data storage extremely seriously. This usually means we >>> work hard to make sure that the underlying storage modules are as robust as >>> we can make them. Sometimes though, we go all the way to the HTTP API to >>> secure against accidental data loss, saving users from their mistakes, >>> rather than dealing with hard drives and kernel caches that usually stand >>> in the way of safe data storage.</p> >>> >>> <h2>The scenario:</h2> >>> >>> <p>To delete a document in CouchDB, you issue the following HTTP >>> request:</p> >>> >>> <code><pre>DELETE /database/docid?rev=12345 HTTP/1.1</pre></code> >>> >>> <p>A common way to program this looks like this:</p> >>> >>> <code><pre>http.request('DELETE', db + '/' + docId + '?rev=' + >>> docRev);</pre></code> >>> >>> <p>So far so innocent. Sometimes though, users came to us and complained >>> that their whole database was deleted by that code.</p> >>> >>> <p>Turns out the above code creates a request that deletes the whole >>> database, if the docId variable isn't set correctly. The request then looks >>> like:</p> >>> >>> <code><pre>DELETE /database/?rev=12345 HTTP/1.1</pre></code> >>> >>> <p>It looks like an honest mistake, once you check the CouchDB log file, >>> but good old CouchDB would just go ahead and delete the database, ignoring >>> the <code>?rev=</code> value.</p> >>> >>> <p>We thought this is a good opportunity to help users not accidentally >>> losing their data. So since late 2009 (yes, this is an oldie, but it came >>> up in a recent discussion and we thought it is worth writing about :), >>> CouchDB will not delete a database, if it sees that a <code>?rev=</code> >>> parameter is present and it looks like that this is just a malformed >>> request, as database deletions have no business requiring a >>> <code>?rev=</code>.</p> >>> >>> <p>One can make an easy argument that the code sample is fairly shoddy and >>> we'd agree. But we are not here to argue how our users use our database >>> beyond complying with the API and recommended use-cases. And if we can help >>> them keep their data, that's a win in our book</p> >>> >>> <p>Continuing down this thought, we thought we could do one better. You >>> know that to delete a document, you must pass the current rev value, like >>> you see above. This is to ensure that we don't delete the document >>> accidentally without knowing that someone else may have added an update to >>> it that we don't actually want to delete. It's CouchDB's standard multi >>> version currency control (MVCC) mechanism at work.</p> >>> >>> <p>Databases don't have revisions like documents, and deleting a database >>> is a simple <code>HTTP DELETE /database</code> away. Databases, however, do >>> have a sequence id, it's the ID you get from the changes feed, it's an >>> number that starts at 0 when the database is created and increments by 1 >>> each time a document is added, updated or deleted. Each state of the >>> database has a single sequence ID associated with it.</p> >>> >>> <p>Similar to a rev, we could require the latest sequence ID to delete a >>> database, as in:</p> >>> >>> <code><pre>DELETE /database?seq_id=6789</pre></code> >>> >>> <p>And deny database deletes that don't carry the latest >>> <code>seq_id</code>. We think this is a decent idea, but unfortunately, >>> this would break backwards compatibility with older versions of CouchDB and >>> it would break a good amount of code in the field, so we are hesitant to >>> add this feature. In addition, sequence IDs change a little when BigCouch >>> finally gets merged, so we'd have to look at this again then.</p> >>> >>> <p>In the meantime, we have the protection against simple coding errors and >>> we are happy that our users keep their hard earned data more often now.</p> >>> >>> -- >>> >>> >> >> >> >> -- >> Noah Slater >> https://twitter.com/nslater > -- Noah Slater https://twitter.com/nslater
