Live data from Hacker News

I’ll Give MongoDB Another Try In Ten Years

diegobasch.com

41–50 of 194 posts

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

#41
post #10

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.

In fairness, this would eventually happen on a 64 bit machine too, just not as quickly.

No excuse for not reading the docs, though.

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

#42
post #5
post #3

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…

What Steve Jobs said is very pertinent to your job as a developer?

Also, you expect it to work in a certain way. That where you are doing it wrong.

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

#43
post #18

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.

One would presume, if you're going to use a database you would check it's limitations first, this one is well documented.

There are plenty of valid arguments for not using MongoDB, but this is the weakest I have seen so far.

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

#44
post #26

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…

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.

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

#45

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

It blows my mind that you'd have to post this at all. Who's writing to mongo without making sure the write succeeded?

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

#46
We've been interviewing candidates to join our team for a few months, and I've also lent some interviewing support to other startups in our area.

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.

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

#47
post #26

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…

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

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

#48
post #39

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.

As I understand it, it has everything to do with the client library, some clients may call getLastError on every operation and raise errors when they occur, for example.

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

#49
i welcome the post. even though most of my stuff runs on 64bit, i actually do have a few 32 bit systems here and there. I never knew. Because as the op mentions it's not written anywhere _obvious_.

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

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

#50

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

Honest question - where would someone with no Mongo experience typically discover that?
Post reply on HN