Live data from Hacker News

I’ll Give MongoDB Another Try In Ten Years

diegobasch.com

171–180 of 194 posts

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

#171

There's a bigger question here. I get why diego was flabbergasted by the default, and I also hear legitimate claims that the documentation should have been read. But what I want to know is: Why are MongoDB advocates in such a bad mood? It's legit to criticize a language or a database. However, it seems to me that when MongoDB gets involved, the tone is far more aggressive and defensive. What's up with that? It's just…

The sentiment is because people:

1) Care.

2) Feel they had wool pulled over their eyes unexpectedly.

Let's talk about the wool. MongoDB was marketed initially with stupid little benchmarks (that were later removed as a policy). Those benchmarks were what people saw, showed their bosses, colleagues and decided -- "this is the one". Yes they picked a bad tool should have RTFM, I would normally say but not for MongoDB.

They marketed themselves as a "database" while at the same time shipping with durability turned off. Yes, you can write very fast if you don't acknowledge that data has hit the disk buffers. I wasn't fooled, I saw the throughput rates and thought, something is fishy. But a lot didn't.

Most of all I have no problem with this design decision given that there is a bright red flashing warning on the front page saying what the default settings are and what it could do to your data. There wasn't.

As developers (programmers whatever you want to call it), we feel that perhaps when other developers market things aimed at us, they would be somewhat more honest than say someone selling rejuvenating magnetic bracelets at 4am in the morning on TV. I think that is where the passionate discussion comes from.

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

#172
post #111

Earlier quoted context omitted.

Is it not relevant for a blog? Your business website? Your toy application? It is even relevant for a chat system! And the flaw of your argument: Even if there are other more important things for an application, let's just make anything else than the #1 feature shit.

I'm just saying some databases are like the mail. A chat system is one such case. And the flaw of your argument: Even if there are other more important things for an application, let's just make anything else than the #1 feature shit. I don't actually understand what you mean, here, but since you say it's the flaw of my argument, I'm very interested in it. Could you rephrase briefly?

I mean is it desirable behaviour? Would you not want a chat program which never dropped your messages? If that's the case, we should work towards it, not accept a 1 of 1000 messages lost because "there are more important things to worry about". The most important feature should be prioritized over less important ones, but it should not make us forget them - they should be as good as possible as well.

I guess what I'm trying to say is this: You cannot ignore all the other features except the biggest one.

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

#173

Earlier quoted context omitted.

People who assume such trivialities would be handled for them like in every other DBMS.

Only inept developers would assume that. EVERY database call should be wrapped in exception handling to make sure that any errors e.g. connection errors are handled appropriately. MongoDB is no different in this case.

Only inept developers would assume MongoDB behaves like a DBMS?

You can only handle the errors that you know how to handle, in this case retrying the operation may have created a bigger problem.

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

#174
post #115

There's a bigger question here. I get why diego was flabbergasted by the default, and I also hear legitimate claims that the documentation should have been read. But what I want to know is: Why are MongoDB advocates in such a bad mood? It's legit to criticize a language or a database. However, it seems to me that when MongoDB gets involved, the tone is far more aggressive and defensive. What's up with that? It's just…

I think you're way off base. Even assuming your claims about experience with traditional databases (which I disagree with), we don't see the same kind of emotional tone when talking about equally new datastores like redis or couchdb. Mongodb was very aggressively marketed; its advocates produced benchmarks comparing it directly to traditional relational databases as though the use cases were the same. I think that se…

I'm not terribly old: 35. Been doing web development as a career since 1999.

More relevant, is my experience. I didn't come in when Java came out. I started (1997-1998) with some high-level dynamic web languages: ASP classic, ColdFusion (To this day, I still do CF - I'm a CF user group manager and I speak at CF conferences). Building HTML and JavaScript since 1996 (GeoCities, HotDog, and HomeSite). Nerded around with programming 1995-1997 in high school (TI Basic, Pascal, and Qbasic) In the days when I started web development, a lot of folks were still monkeying around with Perl and flatfiles. I can't really speak to early days of Java: until 2000, didn't really use it. ColdFusion 6 went from C++ to Java, at which point CF devs ran on the JVM and could target it.

From the beginning I was a consumer of RDBMSes. Started with Access and moved on to SQL Server. There wasn't a need to know the full DB, only the pieces you needed for CRUD. Perhaps for newbs that has changed, and they have to learn the full SQL administrative experience. Personally I doubt that. Do some db migrations in Rails: you don't even need to know what SQL engine you're running on. (A good thing, IMO, but still means a lesser body of knowledge)

Good point that a lot of products try so hard to be the "new sexy" that they suggest an inaccurate comparison, or at best, implement a subset of what they're trying to replace.

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

#175

There's a bigger question here. I get why diego was flabbergasted by the default, and I also hear legitimate claims that the documentation should have been read. But what I want to know is: Why are MongoDB advocates in such a bad mood? It's legit to criticize a language or a database. However, it seems to me that when MongoDB gets involved, the tone is far more aggressive and defensive. What's up with that? It's just…

Well you could just as easily say that the old guard get upset when all their hard-earned knowledge stops being relevant, so they respond emotionally as well. But arguing about nosql is just something that happens around here...

Very true and wise. As a "mid-guard" developer, it's a fight between "get off my lawn" and "pay attention, lest you become old and irrelevant". I like noSQL, but I feel that Mongo has made some sacrifices to move to the front. Given that performance, I think plenty of new devs have sold into it, and get upset easily at challenges. Maybe they'd have a different response were they committed to Riak or CouchDB.

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

#176

Earlier quoted context omitted.

Only inept developers would assume that. EVERY database call should be wrapped in exception handling to make sure that any errors e.g. connection errors are handled appropriately. MongoDB is no different in this case.

Only inept developers would assume MongoDB behaves like a DBMS? You can only handle the errors that you know how to handle, in this case retrying the operation may have created a bigger problem.

Only people who don't read the instructions for what they're using would get bitten by this.

It's like, literally, right there in the brief manual. Takes an hour to read and understand.

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

#177

Earlier quoted context omitted.

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

If it blows your mind that people would write to mongo without making sure the write succeeded, then doesn't that make the default behaviour itself mindblowing? Perhaps a better option would be to have an 'unsafe_write' option. But then of course, benchmarks would look less impressive which didn't use a function with 'unsafe' in the name.

It blows my mind a person wouldn't read the manual.

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

#178

Earlier quoted context omitted.

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

The people over at MongoDB who wrote the tutorial? http://api.mongodb.org/wiki/current/Ruby%20Tutorial.html#Rub...

Then they fucked up.

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

#179
post #72
post #57

Earlier quoted context omitted.

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…

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?

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?

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

#180

Earlier quoted context omitted.

The people over at MongoDB who wrote the tutorial? http://api.mongodb.org/wiki/current/Ruby%20Tutorial.html#Rub...

Then they fucked up.

"It's like, literally, right there in the brief manual. Takes an hour to read and understand."

Huh.

Post reply on HN