When a No means Yes
hackingdistributed.com
When a No means Yes
1–10 of 44 posts
Re: When a No means Yes
#2This guys arguments are really bad because he makes them from a very narrow one sided point of view. It is actually hard to read through the hatred....
Re: When a No means Yes
#3This guys arguments are really bad because he makes them from a very narrow one sided point of view. It is actually hard to read through the hatred....
> First, the 10gen spokesperson seems to have read only the H2 elements on my original writeup -- he seems to not have read or understood the actual text that goes along with them. Do they have some local CSS applied that makes regular text invisible?
Couldn't read past that.
Re: When a No means Yes
#4This guys arguments are really bad because he makes them from a very narrow one sided point of view. It is actually hard to read through the hatred....
Actually he is quite right and MongoDB is a disaster when it comes to data reliability. The fact that some facts are hard to accept as true and cause feelings to be hurt doesn't change their validity. Not every piece of software is good just because a lot of people use it.
Re: When a No means Yes
#5This guys arguments are really bad because he makes them from a very narrow one sided point of view. It is actually hard to read through the hatred....
I don't read it as hatred at all.
If you read the Mongo rebuttal it seems as though they willfully misconstrued the points he made in his original post.
Mongo was broken by default in 2.0, that's why they changed the default behavior in subsequent versions. The author even went out of his way to talk about the changed behavior in his first post.
I don't know, this is the first critique of Mongo I've seen that really attacks Mongo stability and I'm eager to see how Mongo responds. The author is correct that Jason's (from Mongo) response left a lot to be desired.
Yes the author appears to dislike Mongo, but if his reasons are correct and his points are valid, discounting his opinion due to word choice seems unnecessary.
Re: When a No means Yes
#6It was a bit snarky, but the points he made were based in fact not opinion. I personally like and use mongo, but I don't pretend it's perfect.
Re: When a No means Yes
#7We recently have been having to work around an issue that, on top of all the other issues we've had means we're moving away from mongo entirely. The current issue is that a mapreduce on a cluster into a sharded collection will, at some point, start silently not writing 30% of the data into the sharded collection. And from that point onward, roughly the same amount of data is lost any time it goes to that collection. We have to watch for it and create an entirely new sharded collection to mapreduce into, then everything works fine for a while until that one starts not getting some data. When we create a new collection, we just pick a new name, copy all the previous data over, update the MRs to point to that collection and hit go. I would be able to understand data loss caused by certain durability settings from a client, but on mapreduce results?
Re: When a No means Yes
#8This guys arguments are really bad because he makes them from a very narrow one sided point of view. It is actually hard to read through the hatred....
I wouldn't call it hate. He's clearly very frustrated that he carefully worded his points, only to receive responses to points he didn't make.
We've all had those co-workers who come to us with tough to debug problems that we correctly diagnose for them and lay out for them, only to have them gloss over the details and claim the issue we found isn't an issue at all. Their inability to follow the details was the root of their inability to debug the problem. In the case of the blog post, the guy who diagnosed the issue is the one coming to the person with the bug, but this blog post is the same old your-inattention-to-subtle-detail-always-makes-you-come-to-me-I've-always-been-right-in-the-past-so-just-try-my-suggested-fix-before-arguing argument, but happening out in public on the Interwebs.
Re: When a No means Yes
#9This guys arguments are really bad because he makes them from a very narrow one sided point of view. It is actually hard to read through the hatred....
[deleted]
Re: When a No means Yes
#10I almost feel like I am missing out on hating MongoDB with others, because for me it just works, and _nothing_ I have seen people complain about is really a problem for me. Even in this article your upset because if you have multiple threads using a single connection the getLastError message won't always report the query form the current thread ? That's like saying your upset because the linux kernel does not let other threads know your in the middle of a mutation of a memory address so it may get corrupted. Its your fault deal with it.
Then your upset because in the past it didn't preform like you wanted it to so somehow that should be factored into the _current_ reliability ? My takeaway is you didn't care enough about your data in the past to understand your persistence layer why do I feel you are going to do the sane thing in the present and understand your persistence layer now , it appears if it doesn't work like you want it to by default then its broken and 10gen should really be making a datastore just for you. I am more annoyed that I need to now specify that I _don't_ want to wait for confirmation of write, but I at least took the time to understand how the DB works and what I need to do with it.