[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.