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
signature.asc
Description: Message signed with OpenPGP using GPGMail
