Neat! Now I hope someone writes a post to explain the difference between 'eventual consistency' and 'eventually consistent'! Super confusing for me still :s
:D -- Matt On Mon, Apr 7, 2014 at 4:12 PM, Andy Wenk <[email protected]> wrote: > 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(pastedbelow > 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 >
