couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [discussion] New Blog Series: The Little Things
Date Tue, 08 Apr 2014 11:11:43 GMT
Please help to promote:

On Hacker News /newest for the next 30 mins or so

http://www.reddit.com/r/CouchDB/comments/22i9pr/the_little_things1_do_not_delete/
http://www.reddit.com/r/nosql/comments/22i9qr/the_little_things1_do_not_delete_couchdb/

https://lobste.rs/s/royp74/the_little_things_1_do_not_delete

https://twitter.com/CouchDB/status/453489805452910592

https://plus.google.com/u/1/109226482722655790973/posts/4C4P2i66SyU
https://plus.google.com/u/1/109226482722655790973/posts/fnVhZRPUwJT

https://www.facebook.com/permalink.php?story_fbid=525998800765682&id=507603582605204&stream_ref=10

Circulating to user@ and dev@

On 8 April 2014 12:56, Jan Lehnardt <jan@apache.org> wrote:
> 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 <nslater@apache.org> 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 <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>
>>>
>>> --
>>>
>>>
>>
>>
>>
>> --
>> Noah Slater
>> https://twitter.com/nslater
>



-- 
Noah Slater
https://twitter.com/nslater

Mime
View raw message