couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wenk <a...@nms.de>
Subject Re: [discussion] New Blog Series: The Little Things
Date Mon, 07 Apr 2014 21:12:38 GMT
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 <jan@apache.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message