6 ms·

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

by mtkd 14y ago

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 14y ago
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 14y ago
  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 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 14y ago
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
- jfoutz 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
        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.
- pooriaazimi 14y ago
  It's stated plainly and prominently in http://www.mongodb.org/downloads 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.

by mtkd 14y ago

smacktoward 14y ago

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 14y ago
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 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 14y ago

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

jfoutz 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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.
pooriaazimi 14y ago
It's stated plainly and prominently in http://www.mongodb.org/downloads 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.