couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "matt j. sorenson" <m...@sorensonbros.net>
Subject Re: [discussion] New Blog Series: The Little Things
Date Mon, 07 Apr 2014 21:55:00 GMT
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 <andy@nms.de> 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 <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(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
>

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