Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB queries don’t always return all matching documents

engineering.meteor.com

Post reply on HN
Print view View original

231–240 of 419 posts

Re: MongoDB queries don’t always return all matching documents

#231

Post by Renner1 »

nevi-me wrote: post #209
1879325235 wrote: post #204

> 1) Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly). Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql. What is even worse is that, despite nobody here acknowledging it, must SQL databases are used with an ORM. Now in your migration script you have to hac…

I've just commented with pretty much the same as you're saying. Some people sound like they haven't even tried Mongo. It's great that PG has JSON support now, but a few years ago people were having together stuff on hstore, storing their geo objects as binary blobs that you can't read without extensions etc. SQL databases have been playing catch up with JSON, MSSQL being the worst. Even with JSON support, it's still…

> If postgres does it for you, don't go bashing everything else that tries to be an alternative I feel.

People bash on MongoDB because they care. People just want to raise awareness that there are two types of MongoDB users: Those who understand it is a deeply broken system, and those who haven't used it thoroughly. The truly careless and anti-social approach would be for people to leave no negative comments about MongoDB and let others fall into the same trap.

Re: MongoDB queries don’t always return all matching documents

#232

Post by catnaroek »

gaius wrote: post #215
1879325235 wrote: post #204

> 1) Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly). Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql. What is even worse is that, despite nobody here acknowledging it, must SQL databases are used with an ORM. Now in your migration script you have to hac…

I have been a DBA for 20 years, Oracle, SQL Server, Sybase, Informix, Postgres, MySQL/MariaDB... About the only big name I haven't had serious experience with is DB2. We did hot-releases into Prod routinely. I have absolutely no idea what a "SQL migration" is or why it would be so hard. I assume it's just a bogeyman made up by the MongoDB snake-oil salesmen. It is certainly not something "traditional" database people…

> I have absolutely no idea what a "SQL migration"

Transforming data to conform to a new schema. It's a tedious process that could use some automation, but ditching schemas because data migrations are tedious is like ignoring traffic rules because you're in a hurry.

> I assume it's just a bogeyman made up by the MongoDB snake-oil salesmen.

It's just like dynamic type marketing: “If you never define the structure of your data, you never need to worry about it!” The only problem is that it isn't true.

Re: MongoDB queries don’t always return all matching documents

#233

Post by arctor »

xapata wrote: post #160
red_hare wrote: post #149

Earlier quoted context omitted.

This. My company used mongo for years before we got our shit together. Schmemas were always implicit (until we got our shit together and started defining and enforcing them with Python Schematics). Migrations were crazy scripts you run in prod or hacks you stick into your code to "transition". And yes, surprise constrains left and right causing awful anti-patterns. One-character key names to save disk. Hashed values…

> used mongo for years before we got our shit together. That's actually a legit use case. Use MongoDB while you get your shit together. I use global variables while I'm noodling around in code. Eventually I refactor.

The problem is, in a great portion of real world projects "eventually" never comes and there's just no time for any major refactoring or replacing technologies since you are too busy implementing the feature that was needed two weeks ago.

Re: MongoDB queries don’t always return all matching documents

#234

Post by derefr »

red_hare wrote: post #149
Lazare wrote: post #124

Earlier quoted context omitted.

> Because some people can't stand having to work with SQL,migrations,schema and constraints The thing is, if you actually try and write an app using MongoDB, you will rapidly find that you: 1) Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly). 2) Have schemas (except they'll be implicit and undocumented) 3) Constraints (exce…

This. My company used mongo for years before we got our shit together. Schmemas were always implicit (until we got our shit together and started defining and enforcing them with Python Schematics). Migrations were crazy scripts you run in prod or hacks you stick into your code to "transition". And yes, surprise constrains left and right causing awful anti-patterns. One-character key names to save disk. Hashed values…

Likely better to scrape the data out through the app (if it's a web app) than to try to talk to that sort of database directly. The app would at least put names to everything.

Re: MongoDB queries don’t always return all matching documents

#236

Post by rhizome »

im_down_w_otp wrote: post #92
spriggan3 wrote: post #76

Earlier quoted context omitted.

> Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? Because some people can't stand having to work with SQL,migrations,schema and constraints, it's as simple as that ( That's not my opinion,that's just the rational behind MongoDB). Even if you use Postgres with the Json column type, you still need to write SQL queries and schemas. In the context of…

Is having seen something used some way a leading indicator of it being a good idea to have used that thing that way? Because I've seen Excel used as database with all kinds of macros and VBA scripts bolted-on/embedded to provide the workbook various shapes of stored-procedure and query capability... but, while sorta impressive in a "Holy crap, lol wut?" kind of way, I'm not sure any instance I observed of uses like t…

In my experience in market research, advanced spreadsheet programming with macros and pivot tables and whatnot are more a contemporary incarnation of Reporting than raw database querying and operations.

Re: MongoDB queries don’t always return all matching documents

#237

Post by derefr »

arctor wrote: post #233
xapata wrote: post #160

Earlier quoted context omitted.

> used mongo for years before we got our shit together. That's actually a legit use case. Use MongoDB while you get your shit together. I use global variables while I'm noodling around in code. Eventually I refactor.

The problem is, in a great portion of real world projects "eventually" never comes and there's just no time for any major refactoring or replacing technologies since you are too busy implementing the feature that was needed two weeks ago.

I've often dreamed of a specific type of software built and released as "prototypeware", where any app created using it will have certain built-in scaling limits—and going past them will irrevocably force the app into a read-only mode. It would warn anyone monitoring it well in advance of hitting such a limit, of course. But there'd be no way to just slide the limit upward or otherwise tarry. It'd force the migration to something better just as if it were a Big Customer with Enterprise Compliance Demands.

If an enforceable mechanism like that existed, I'd be a lot more confident in mocking things up. Stick SQLite in for the database, munge HTML and Javascript together, whatever—it's literally going to slap away the hand of anyone who tries to use it on a production workload, so why not?

(Going further, it'd be interesting to create some sort of quagmire of a software license, specifically for prototypeware, such that you'd be forced to rewrite all the prototype code instead of reusing even a hair of it in production. Maybe something like reassigning the IP to a trust, with the trust having an obligation to sue anyone and everyone who tries to create derivative works of the code they've been handed?)

Re: MongoDB queries don’t always return all matching documents

#239

Post by dijit »

manigandham wrote: post #175
Pxtl wrote: post #101

Earlier quoted context omitted.

Because postgres doesn't focus on the first-five-minutes experience the way Mongo does. Even the name is hard to say. Mongo is a dumb, dead-end platform, but they know how important ease-of-use is.

This is key and often overlooked - MongoDB is so popular not because it's the best database but because it's so easy to get started with. Download/unzip/run to have a database engine ready. It also helps that you can also immediately store anything without any prior setup steps. Postgres/mysql/sqlserver/etc are nowhere near as easy to install, as fast to get started with or as portable to move around.

Well, that's not entirely true.

if you're on a mac you can download postgresql.app[0] which produces a small icon in the top right status bar. You don't have to install users or permissions or anything it's super easy to set up. Getting it on prod can come later but for the first five minutes it works.

(granted, this neglects contrib extensions like hstore)

[0] http://postgresapp.com/

Re: MongoDB queries don’t always return all matching documents

#240

Post by derefr »

SmirkingRevenge wrote: post #219
m_mueller wrote: post #118

Earlier quoted context omitted.

So my question is then: Why not use CouchDB instead? I don't see what Mongo gives you over that and CouchDB is at least dependable and predictable in its operation.

I really like Couch, I wish it had more adoption than it seems to have and that its ecosystem was more mature than it seems to be... and that javascript wasn't its first class citizen. But its a really cool database (though I'm partial to rethinkdb now)

Even Javascript is sort of a second-class citizen in Couch. The real first-class citizen is native Erlang code running unsandboxed in the server context. If you want high(er) performance, that's where you go. (Alternatives to this have been discussed, like embedding the luerl Lua interpreter to give the option of a sandboxed programming target without the IPC cost. Nothing in the immediate pipeline, though.)
Post reply on HN