[mtkd]

This is the latest in a long line of negative posts on MongoDB based solely on first impressions because either:

1) it does not behave exactly like SQL

2) the user didn't read any more than a Quickstart Guide

3) the user fundamentally misunderstands the aim of the new technology or the application it is intended for

Ember.js suffers from the same ignorance.

What makes it worse is all the morons who upvote without even reading the detail purely because the title reinforces some misconceived bias they already have.

'NoSQL' is part of the problem. This technology has absolutely no comparison with SQL other than it persists data.

[smacktoward]

This technology has absolutely no comparison with SQL other than it persists data

Except that apparently under certain circumstances it doesn't persist data, which was the author's point.

Personally I wouldn't be upset about a limitation like the one described as much as I would be upset about the database not logging an error when it discards the data. Logs are a primary way you figure out what's wrong when your application isn't behaving as expected. If you open the logs and see a bunch of "32-bit capabilities exceeded, please buy a real computer" messages, you learn what the problem is. If the database error logs are empty, that implies that everything is working fine, when in this case it clearly isn't.

[ukd1]

You can get MySQL to do dumb stuff as well, though you have to specifically ask it to take more risks - http://dev.mysql.com/doc/refman/5.5/en/insert-delayed.html

Almost all of the complaints against MongoDB are down to assumptions and lack of understanding about the database.

[linuxhansl]

I'm sorry. Which part of "It silently ignored my data" do you not understand?

You call people "morons", yet it appears that you did not read the article yourself.

Whether SQL or not, scalable or not, old or new, or whatever... Is completely immaterial here.

When a database silently stops accepting data, and apparently has done so for 3 years, you have to at least admit that there are strange design goals at play.

Now, the entire claim of the article might be incorrect. Did you verify that yourself?

Edit: Spelling

[pooriaazimi]

It's stated plainly and prominently in http://www.mongodb.org/downloads that 32-bit version is limited to 2GB. It's mentioned elsewhere in the documentation, but the OP didn't bother to read them. "A gem and two lines" and it worked, so he expected it to work forever. That's not how engineers usually work. Most of the time, they over-engineer, not the other way around! They research the hell out of any new technology they want to use. I'm definitely less talented than OP and others on HN, but even I know a hell of a lot about Redis, MongoDB and CouchB, and I haven't even started to write a line of code.

And anyone who has read more than an introduction to mongo knows that you SHOULD use getLastError to be safe. If you do that, no data will be dropped.

[zzzeek]

I think they need to change the word "limit". This is what "limit" means:

    [root@li321-238 tmp]# dd if=/dev/zero of=./filesystem bs=1M count=128
    [root@li321-238 tmp]# mkfs.ext2 filesystem 
    [root@li321-238 tmp]# mount -o loop filesystem myfilesystem
    [root@li321-238 tmp]# dd if=/dev/zero of=myfilesystem/im_too_large bs=1M count=129
    dd: writing `myfilesystem/im_too_large': No space left on device

that is, a "limit" means, the program stops, complains. It's "limited".

A program that continues along without issue, only changing its behavior in some unannounced (documented or not) way, is not "limited". It's free as a bird.

[jfoutz]

I think you're overlooking asynchronous writes. Exceptions kind of suck in the asynchronous world, because you need to clean up the write error and you have no idea where you are in your code.

With a getLastError model, you can do your work, then go check for errors when you're really ready.

I'm not saying it's a great api, but it does make sense in context. No idea why the tutorial the op followed didn't talk about the differences, or why asynch is hard.

[untog]

Surely "getLastError" is an extremely questionable concept in the asynchronous world? How do I know the 'last' error is the one relating to the operation my code just executed?

[grey-area]

Presumably this has to be done in the driver directly after the insert call - on the same connection, to ensure that you actually get the last error, and not someone else's error, if you have several instances writing to the db?

[prodigal_erik]

Mongo's wire protocol actually has request IDs, but it appears db.$cmd.findOne({getlasterror:1}) doesn't use that. Instead you have to send it over the same connection as the operation in question, and if you had to reconnect you're just fucked and will never know what you may or may not have committed.

[kordless]

I really wish people here would start being nicer to each other. Thanks for calling him on it.