awesome! I like the idea a lot and also the article. I think it is very cool, that it's short and readable in about three to five minutes. The benefit is that you can only transport one tiny thing in a short post like this and the interested reader will keep it in mind.
So +1 especially for the format :) Maybe we can also find a good place in the cwiki to collect the references to the posts ... Cheers Andy 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> > > -- > > > -- Andy Wenk Hamburg - Germany RockIt! http://www.couchdb-buch.de http://www.pg-praxisbuch.de GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 https://people.apache.org/keys/committer/andywenk.asc
