Live data from Hacker News

I’ll Give MongoDB Another Try In Ten Years

diegobasch.com

101–110 of 194 posts

Re: I’ll Give MongoDB Another Try In Ten Years

#101

It's almost like the commenters who are bashing the author of the post did not read the bit in bold, which is his main point: If you tell a database to store something, and it doesn’t complain, you should safely assume that it was stored. This has nothing to do with the 2Gb limitation. Nowhere in the documentation does it mention that it will silently discard your data. What will happen with the 64-bit version if you…

> Nowhere in the documentation does it mention that it will silently discard your data. Demonstrably false. http://www.mongodb.org/display/DOCS/getLastError+Command "MongoDB does not wait for a response by default when writing to the database. Use the getLastError command to ensure that operations have succeeded."

In the classic "MongoDB is Web Scale", it is recommended to use the "dev null" storage engine for this use case.

Re: I’ll Give MongoDB Another Try In Ten Years

#102
post #21
post #7

Earlier quoted context omitted.

> It doesn't have table-locking writes?! :) Not really following the snark there. Are you trying to compare MongoDB to MySQL's MyISAM storage engine? Like there aren't numerous other extremely valid RDBMS solutions out there, which don't do table locks during a write? (MySQL InnoDB, Percona, Maria, Aria, Postgresql, Firebird, etc...)

No. He is saying out of all faults Mongo has - blog author picks the one which is rather well known.

Worse, it's the necessary tradeoff of one of MongoDB's self-proclaimed benefits (asynchronicity) - it's not an edge case; it's part of the core reasons you'd switch to MongoDB (or at least take into account when making that choice). If that surprises you, it's because you haven't switched for the right reasons or haven't researched enough to know that every benefit has a tradeoff (and to know what those tradeoffs are).

To give an analogy, it'd be as if someone read this post and decided to use a SQL database solely because they care about write-durability... and then complaining when they "suddenly" encounter an error when trying to include an extra field with an INSERT on-the-fly. ('You mean SQL has fixed schemas??')

Re: I’ll Give MongoDB Another Try In Ten Years

#103
post #58
post #50

Earlier quoted context omitted.

Honest question - where would someone with no Mongo experience typically discover that?

For one, it's mentioned in Chapter 5: When To Use MongoDB in The Little MongoDB Book. http://openmymind.net/mongodb.pdf

That isn't official documentation as far as I can tell, though. I don't think I should need to read 5 chapters into a separate book for something so seemingly fundamental.

IMO, this is important enough information that it should be mentioned from the start, but it isn't in the tutorial[1], nor can I find it in the FAQ[2].

[1] http://www.mongodb.org/display/DOCS/Tutorial [2] http://docs.mongodb.org/manual/faq/

Re: I’ll Give MongoDB Another Try In Ten Years

#104

Earlier quoted context omitted.

I fail to understand how and why silent failure is considered a reasonable default.

It actually happens in some scenarios. Let's say, outside of the tech world: When you send a post card (cheap ones) to a friend, you won't receive any delivery confirmation. You just send it and go do whatever you please, believing the post card will be there. If the envelope don't get there, no biggies, you will send another on your next trip anyways. No hurt feelings. But, let's say you need to send me a check. You…

Databases are not like the mail. Databases are like a bank.

If I ask my bank why my account does not reflect my latest deposit and they say 'Sorry, I guess we didn't get it', I'm getting a new bank.

Re: I’ll Give MongoDB Another Try In Ten Years

#105
post #103
post #58

Earlier quoted context omitted.

For one, it's mentioned in Chapter 5: When To Use MongoDB in The Little MongoDB Book. http://openmymind.net/mongodb.pdf

That isn't official documentation as far as I can tell, though. I don't think I should need to read 5 chapters into a separate book for something so seemingly fundamental. IMO, this is important enough information that it should be mentioned from the start, but it isn't in the tutorial[1], nor can I find it in the FAQ[2]. [1] http://www.mongodb.org/display/DOCS/Tutorial [2] http://docs.mongodb.org/manual/faq/

You're right, it's not official documentation, but it was the first thing I read when I decided to start learning Mongo. I've also seen 10gen hand out hard copies at meetups in NYC. Anecdotal, I know, but maybe helpful to someone.

There's also a reference to the issue in your second link, though it's not super clear. http://docs.mongodb.org/manual/faq/replica-sets/#are-write-o...

Re: I’ll Give MongoDB Another Try In Ten Years

#106

Earlier quoted context omitted.

It actually happens in some scenarios. Let's say, outside of the tech world: When you send a post card (cheap ones) to a friend, you won't receive any delivery confirmation. You just send it and go do whatever you please, believing the post card will be there. If the envelope don't get there, no biggies, you will send another on your next trip anyways. No hurt feelings. But, let's say you need to send me a check. You…

Databases are not like the mail. Databases are like a bank. If I ask my bank why my account does not reflect my latest deposit and they say 'Sorry, I guess we didn't get it', I'm getting a new bank.

...and if you're building a banking app, that's relevant. If you're building a chat system, maybe things other than data integrity matter more.

Re: I’ll Give MongoDB Another Try In Ten Years

#107
post #96

Earlier quoted context omitted.

It actually happens in some scenarios. Let's say, outside of the tech world: When you send a post card (cheap ones) to a friend, you won't receive any delivery confirmation. You just send it and go do whatever you please, believing the post card will be there. If the envelope don't get there, no biggies, you will send another on your next trip anyways. No hurt feelings. But, let's say you need to send me a check. You…

Surely you don't think that this is a reasonable model for how a database should work, do you?

If you can turn that behavior on and off (by using getLastError or whatever), why not have this feature?

If I'm logging upvotes on a post or comments on a blog, which is about as serious as 99% of these b.s. startups are doing, I think it's fair to ignore errors.

I do agree that this should be pointed out in huge blinking letters though, or be a driver flag that is on by default. The amount of people who don't know this about Mongo, but are still using it to store gigs of data, is horrifying.

Re: I’ll Give MongoDB Another Try In Ten Years

#108

It's almost like the commenters who are bashing the author of the post did not read the bit in bold, which is his main point: If you tell a database to store something, and it doesn’t complain, you should safely assume that it was stored. This has nothing to do with the 2Gb limitation. Nowhere in the documentation does it mention that it will silently discard your data. What will happen with the 64-bit version if you…

it's called getLastError

So, they do return an error, just not throw an exception. Isn't that what people most like/hate about Golang?

Re: I’ll Give MongoDB Another Try In Ten Years

#110
Isn't the write result containing the info? e.g. if the write failed, it will contain the error if you just check for it? if so, and I haven't checked (but I assume it's so) then this post is equivalent to ranting on Go's lack of exception handling. like it, don't like it, it is what it is, you can either use it, or fork it and make your own database / language.
Post reply on HN