

CouchDB Notice for 1.0.1 - Potential Data Loss - amock
http://couchdb.apache.org/notice/1.0.1.html

======
coffeemug
Critical bugs are a question of statistics. As the size of the code-base
increases, the probability that there is a critical bug in it quickly
approaches one. Who would dare say that millions of lines of core Oracle code
do not have at least five obscure bugs that cause data loss in some
situations?

~~~
Aaronontheweb
There's always going to be some edge case that escaped test coverage or some
use case that totally escaped the imaginations of developers in any product.
The chances of such an error being discovered is probably a function of the
total number of active application instances and some rough measure of
complexity in the application's implementation. So yeah, I'd say generally
speaking you're right on.

------
couchdb
I should make clear that the notice is titled "Notice for 1.0.1" because the
1.0.1 release (due this week) will contain the fix. The bug is confined to
1.0.0.

~~~
freetard
I hope next time Damien will think twice before insulting other databases for
having similar issues:

<https://twitter.com/damienkatz/status/15444148375>

~~~
StavrosK
As I saw the tweet I became uneasy, followed the link and, sure enough, it's
my post he's referencing. That's a bit disconcerting, I feel responsible for
trashing MongoDB all over the internet. At least my conscience is lighter
because everything I wrote was true...

~~~
pierrefar
For pete's sake, for the last time: you were using 1.3.3 which is UNstable and
not production ready. Its developers know it's likely to have problems and you
proved them right. What you wrote was not "true". You found a bug in beta
software.

This instance of CouchDB data corruption is in a production-ready version, aka
a stable version. No doubt eventually MongoDB will hit a similar issue and
then we'll all calm down and stop poo-pooing all the hard work everyone is
putting in building these databases.

~~~
StavrosK
For the zillionth time: I moved to 1.4.0 after 1.3.3, and there was data loss
on the stable version too. Seriously, what's up with everyone's reading
comprehension?

~~~
pierrefar
My understanding is that you stopped using MongoDB and started using SQLite.
To me, that means that you are probably not a Linux or Mac or Windows user
because they all can crash and lose your data. Likewise you are not a user of
any office suite because you've likely to lose data from all of them.
Likewise, even ISPs can disconnect you half-way through a transaction (say
buying something or editing a blog post) and so you will stop using them
because of that.

So good luck with historious. I think it's an interesting idea, but by your
logic I shouldn't try it in case it crashes and loses my bookmarking data.

~~~
StavrosK
I'm pretty sure that my wariness of losing data would mean that I'm... uh...
less likely to lose data? Besides, SQLite is amazing.

------
rcoder
Does anyone else find it interesting that the actual underlying bug causing
this data loss is related to what seems to amount to a stateful variable?
I.e., the "reference to [a] timer is kept in the updater state", and the
actual bug being a process which "never cleared the timer reference".

I think this might suggest an additional criteria for extra code review
scrutiny in systems (like CouchDB) that are built in functional langages: any
code that "feels" stateful or procedural should probably be examined with
additional care, as it is the most likely to contain exactly this classic sort
of stateful logic error.

------
whyme
So much for relaxing.

~~~
Devilboy
Sounds like they were a bit too relaxed on the code reviews.

------
Aaronontheweb
RavenDB seems like a cool document DB option for .NET / Windows devs - has
anyone tried it?

<http://www.ravendb.net/>

