The world is moving towards 64 bit. 9 out of 10 machines I lay hands on run 64 bit. Just move on and stop complaining.
No excuse for not reading the docs, though.
41–50 of 194 posts
The world is moving towards 64 bit. 9 out of 10 machines I lay hands on run 64 bit. Just move on and stop complaining.
No excuse for not reading the docs, though.
Just read the documentation and learn the APIs, this is what happens when you just copy and paste code from a tutorial.
This type of attitude is not constructive. Of course I read the documentation. Much more than "copy and paste from the tutorial." I looked at tons of code samples as needed, read blog posts, etc. The limitation wasn't obvious at all. This reminds me of the attitude that I had to correct in developers that worked for me: - There is a huge difference between "it works" and "it does what the user expects in a friendly w…
Also, you expect it to work in a certain way. That where you are doing it wrong.
It's pretty incredible that the author of a post called "I’ll Give MongoDB Another Try. In Ten Years." criticises a comment on this same post telling him to read the tutorial all the way through as "unnecessarily aggressive". Aside from that, though, the 32 bit limitation is clear in the documentation and present on the download page. It's fine not to read the documentation before you use something but you can't then…
See my comment below. If you use a package manager you never see the warning.
There are plenty of valid arguments for not using MongoDB, but this is the weakest I have seen so far.
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 eve…
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.
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."
I've noticed a trend across about 20+ candidates, all of whom are smart people: people are using Mongo without actually understanding what the hell it's trying to solve by getting away from the RDBMS paradigm.
I'm not sure if this is because 10gen markets it as a general purpose tool, but I have yet to talk with a candidate who can actually describe why they were using the DB vs. a SQL database. I'm all for learning new things, but I can't help but wonder if the string of negative MongoDB posts is coming from people who pick it b/c it's new, then realise pretty far in that this is nothing like a normal DB, and "having no schema" isn't really a reason to go with a tool as foundational as a data store.
I think Mongo is great for really specific problems that its designed to solve. It's probably pretty bad for a general purpose tool, but I'd be surprised if anyone serious actually considers it one.
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 eve…
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
Interesting that you're quoting the zen of python, but using ruby. I wonder if the python mongo client would have the same behaviour. There seems to be a number of people commenting, telling you to read the documentation, but I'm with you, that is completely counter-intuitive behaviour and should be viewed as a bug.
This has nothing to do with the client library, so it would not matter which language you use to interface with MongoDB.
another thing I didn't realize was that because of the memory mapped systems which i guess is fine performancewise it's hard to estimate memory usage on a machine. from what I understand there is no possibility to limit the memory usage. Which means that the only way you can limit the amount of memory used is by keeping the size of the database below your memory. quite important things to know imho.
here's an interesting post mentioned in the comments: http://www.zopyx.com/blog/goodbye-mongodb
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."