RavenDB seems like a cool document DB option for .NET / Windows devs - has anyone tried it?
CouchDB Notice for 1.0.1 - Potential Data Loss
21–30 of 33 posts
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#22Critical 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?
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.
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#23Earlier quoted context omitted.
Jesus, I can't believe people still defend this shit. I don't care if MongoDB can store ten jiggerbytes, it should give an error when you're trying to insert more than that . When the hell did corrupting your data become acceptable for a datastore?
The 32bit version is available for convenience, nobody uses it in prod. You can't complain that a simple testing tool limited to 2gb can't store more than 2gb.
unless you run on EC2 and don't need a large instance (which is where 64 bit starts)
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#24Earlier quoted context omitted.
I hope next time Damien will think twice before insulting other databases for having similar issues: https://twitter.com/damienkatz/status/15444148375
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...
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.
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#25Earlier quoted context omitted.
fwiw, the only error Damien made was failing to review some patches other people wrote. Also, this issues is much less serious than the Mongo problems as it's A) localized and B) fixed. Eg it's a bug not a design decision.
Errors: - not reviewing - poor testing procedures - new code in 1.0.0???? Why your claim that its not as bad as mongo is crazy and self serving: - poor code quality is MUCH worse than a design you don't agree with. how could anyone trust couch? at least mongo is upfront about their design decisions, whether you agree or not - the couch team has gone on and on recently about how unreliable mongo is, and yet here is th…
I don't believe the emergence of a single bug tarnishes an entire codebase and labels it as poor quality. This situation seems like a lapse of judgement in process, which they've fessed to and provided a path to correction for.
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#26Earlier quoted context omitted.
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...
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…
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?
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#27Earlier quoted context omitted.
You used a dev version of a tool that is not meant to be ran in production or for any serious task and then complained it didn't work with your attempt. As this bug is not present in the real prod version of mongodb, it doesn't make sense to criticize mongodb for it. Also next time RTFM before using a tool you don't know much about.
I feel this is a justifiable defense, if you use a pre-release version of anything you should recognize that you are taking a risk.
The 32-bit stable versions have the same behaviour, and the MongoDB guys on IRC did admit that data corruption is not a very elegant way to handle it.
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#28Earlier quoted context omitted.
Jesus, I can't believe people still defend this shit. I don't care if MongoDB can store ten jiggerbytes, it should give an error when you're trying to insert more than that . When the hell did corrupting your data become acceptable for a datastore?
Simple guide to keep your integrity in the software business: don't crap on other peoples products and admit your own mistakes.
I'm confused, are you talking about me or MongoDB? If you're talking about me, I don't think I made a mistake, and if you're talking about MongoDB, the guys on IRC were very civil about it and did say that silently corrupting data was the wrong way to go about it.
It's these apologists who are giving MongoDB a bad name, really, because the guys on IRC were nothing but helpful about it.
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#29Earlier quoted context omitted.
Simple guide to keep your integrity in the software business: don't crap on other peoples products and admit your own mistakes.
I'm confused, are you talking about me or MongoDB? If you're talking about me, I don't think I made a mistake, and if you're talking about MongoDB, the guys on IRC were very civil about it and did say that silently corrupting data was the wrong way to go about it. It's these apologists who are giving MongoDB a bad name, really, because the guys on IRC were nothing but helpful about it.
Sorry, this should have posted this under the Katz tweet link. My bad.
Re: CouchDB Notice for 1.0.1 - Potential Data Loss
#30Earlier quoted context omitted.
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…
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?
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.