161–170 of 194 posts
I agree with posts stating that you should read the docs before using a tool you don't know. But I also think that these two really important points should be mentioned in the Getting Started guide, in bold: - The 32bit 2GB limitation (seriously when I started with MongoDB I wasn't expecting this!) - The fire-and-forget policy These are really not points to be discovered in chapter whatever of the docs.
While this article is a bit flippant, I think ten years is a pretty good number when you consider the vast amount of engineering effort that has already been poured into projects like Postgres. This brings me back to the recent discussion about reading other people's code: it is almost certainly smarter to extend an existing database until it's capable of meeting your needs, rather than write one from scratch. The fa…
People need to stop acting like PostgreSQL is some holy grail database. It isn't.
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?
People who assume such trivialities would be handled for them like in every other DBMS.
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.
Earlier quoted context omitted.
Surely you don't think that this is a reasonable model for how a database should work, do you?
If you can turn that behavior on and off (by using getLastError or whatever), why not have this feature? If I'm logging upvotes on a post or comments on a blog, which is about as serious as 99% of these b.s. startups are doing, I think it's fair to ignore errors. I do agree that this should be pointed out in huge blinking letters though, or be a driver flag that is on by default. The amount of people who don't know t…
Acceptable software, particularly in the class of databases, is obligated to tell you that it didn't complete your request. This is not an option.
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…
I'm really glad I haven't deployed mongo now in a production 32-bit system.
Response to EDIT2: Where can data loss be acceptable? If you are having a relatively speedy message system where messages are removed/outdated on rx. I'm sure there are other specialty needs.
A lot of bashing of MongoDB lately is a sign to give a technology at least a try.
Great point. That's usually how you to tell when a technology is starting to disrupt things. Really smart people / experts in their field (which Diego definitely is) start to bash it. In this case, he has a point but has way overblown things. But that's ok, that means Mongo is on the right track.
Earlier quoted context omitted.
Databases are not like the mail. Databases are like a bank. If I ask my bank why my account does not reflect my latest deposit and they say 'Sorry, I guess we didn't get it', I'm getting a new bank.
...and if you're building a banking app, that's relevant. If you're building a chat system, maybe things other than data integrity matter more.
I take your point though, but I think consistency is still one of the most important attributes for anything that is going to store data. Why even use a database, if your data matters so little? Just throw it into memory or memcache.
While this article is a bit flippant, I think ten years is a pretty good number when you consider the vast amount of engineering effort that has already been poured into projects like Postgres. This brings me back to the recent discussion about reading other people's code: it is almost certainly smarter to extend an existing database until it's capable of meeting your needs, rather than write one from scratch. The fa…
10 years and PostgreSQL still has no easy, manageable solution for replication or sharding. And it's JSON support is still nothing more than a bolted on hack on top of a BLOB. People need to stop acting like PostgreSQL is some holy grail database. It isn't.
And making a solid, featureful, and performant database is vastly harder.
Earlier quoted context omitted.
It actually happens in some scenarios. Let's say, outside of the tech world: When you send a post card (cheap ones) to a friend, you won't receive any delivery confirmation. You just send it and go do whatever you please, believing the post card will be there. If the envelope don't get there, no biggies, you will send another on your next trip anyways. No hurt feelings. But, let's say you need to send me a check. You…
Databases are not like the mail. Databases are like a bank. If I ask my bank why my account does not reflect my latest deposit and they say 'Sorry, I guess we didn't get it', I'm getting a new bank.
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…
I've usually used pymongo [1] for my API docs, and I don't believe I've ever seen this limitation listed there. I also rummaged around the admin area of the mongodb site and don't recall seeing the limitation there. I'm really glad I haven't deployed mongo now in a production 32-bit system. Response to EDIT2: Where can data loss be acceptable? If you are having a relatively speedy message system where messages are re…
So by default Mongo write operations are asynchronous and you have to explicitly ask for error codes later.