Hacker News new | comments | show | ask | jobs | submit login

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.

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


Yeah, manual. Like I said in the other comment.

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.

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.

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.

Manual, not tutorial.

Me: "MongoDB, please store this: ..."

MongoDB: "Done!"

[Ed: The following is an unusual default requirement]

Me: "MongoDB, did you store what I asked?"

MongoDB: "Nope! Good thing you checked!"

But if you actually read about how it works...

Me: "MongoDB, please store this: ..."

MongoDB: "Okay, I've accepted your request. I'll get around to it eventually. Go about your business, there's no sense in you hanging around here waiting on me."

Or, if you really want to be sure it's done:

Me: "MongoDB, please store this. It's important, so let me know when it's done."

MongoDB: "Sure boss. This'll take me a little bit, but you said it's important, so I'm sure you don't mind waiting. I'll let you know when it's done."

Thank you for taking the time to respond in kind; I do not disagree with what you have stated. I disagree with choosing this by default; it violates the principle of designing tools and APIs for use by the general programming public in such a way that they fall into the "pit of success". http://blogs.msdn.com/brada/archive/2003/10/02/50420.aspx

To me, the choice of performance over reliability is the hallmark of mongodb, for better or worse.

I agree with you, incidentally. I think it might be a better design decision to be slower (but more reliable) and to fail loudly by default (10gen has started down this path a few versions ago, by turning journaling on by default). It's messy, but messes get peoples' attention, at least.

That said, I think that people really do overblow the issue and make mountains out of that particular molehill, because all the tools are there to make it do what you want. Many times, it comes down to people expecting that MongoDB will magically conform to their assumptions at the expense of conforming to others' assumptions. Having explicit knowledge of the ground rules for any piece of technology in your stack should be the rule rather than the exception.

People who think reading is overrated.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact