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

261–270 of 419 posts

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

#261

Post by orf »

1879325237 wrote: post #250
Lazare wrote: post #223

Earlier quoted context omitted.

> Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice. The difference between, eg, merging your "first_name" and "last_name" f…

> I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice. The difference between, eg, merging your "first_name" and "last_name" fields into a single "name" field with Mongo or a SQL DB is basically that the SQL DB has better tooling so it'll be cl…

Tl:dr - you used a crappy ORM and now think all ORM libraries sick. So... use MongoDB... which is always accesses through an ORM...

All your comments come across as confused mate. Enforcing arbitrary constraints belongs in the business logic of your app, but dealing with consistency issues does not. Postgres handles row constraints just fine, you can enforce any arbitrary logic (i.e colX != colY and its not the first Tuesday of the month), combined with stuff like expression indexes, json type and actual schemas leaves me confused as to why you would advocate mongo so hard.

Just because you write your migrations in a language like JavaScript doesn't mean it's any better than pure SQL.

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

#262

Post by orf »

1879325237 wrote: post #255
EpicEng wrote: post #216

Earlier quoted context omitted.

Thank you. Not everything is easy. This is the difference between engineering and 'hacking'. Hacking is not something to aspire to; it's something you do because of crushing, external pressures.

Hacking is trying to get the SQL representation into something programmers use via the way of an ORM. At the end of the day, a SQL database doesn't represent the data in a way the programmer uses the data. It has to be transformed and that is a bigger hack than loosening some constraints.

> At the end of the day, a SQL database doesn't represent the data in a way the programmer uses the data.

Errrr that's exactly what they do, unless you've got a terrible schema and havent thought about your data enough. The thing is about 'sql databases' is you can use the power of sql to fetch the data in any representation you want.

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

#263

Post by bbcbasic »

1879325237 wrote: post #245

This is exactly what I thought. You are a DBA. You are not a programmer. Whenever I read these threads I think "either these people are all DBAs or they have an extreme emotional attachment to a particular database". There it is - this is a thread full of DBAs rebelling against a database that takes away their power and responsibility.

Mongo requires no administration then?

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

#265

Post by ckastner »

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.

I don't think that is an apt comparison. Replacing your database backend, at the minimum, usually requires a massive migration of data, and possibly even changes to your entire architecture.

A refactoring does not change behavior, and can be perfomed in minor -- and in your example of a global variable, perhaps even trivial -- increments.

edit: typo

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

#266

Post by dspillett »

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.

There is nothing as long lasting as a temporary solution.

I've just fixed up some code marked "proof of concept" that had been in production for a decade...

Admittedly some people's PoC work is better than what some consider to be release ready, but still this was not intended to be in that state for that long.

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

#267

Post by hathym »

hardwaresofton wrote: post #146
brightball wrote: post #136

Earlier quoted context omitted.

How does it compare to Couchbase? That seems to be lighting the world on fire in that space lately.

I'm not sure if lack of overbearing marketing speak counts for something, but RethinkDB definitely has that going for it. I'm not an expert on couchbase (and neither on RethinkDB, to be frank, though I am a huge fan), but here's what RethinkDB has going for it: - Changefeeds - easily open a persistent connection to the server and get updates when the results of an almost arbitrary query changes. - Joins - Expressive…

horizon is already here https://horizon.io/

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

#268

Post by gaius »

1879325237 wrote: post #245

This is exactly what I thought. You are a DBA. You are not a programmer. Whenever I read these threads I think "either these people are all DBAs or they have an extreme emotional attachment to a particular database". There it is - this is a thread full of DBAs rebelling against a database that takes away their power and responsibility.

"Power" in an organisation is the formal authority necessary to fulfill your reponsibilities. The choice of a particular database technology doesn't make the responsibility for the security, availability etc of the data "go away". As I say you can outsource the mundane tasks like "doing backups" but the buck still stops with someone. If you don't know who that is, it might be you...

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

#269

Post by _halgari »

vegabook wrote: post #166
pixelmonkey wrote: post #102

Earlier quoted context omitted.

Genuinely curious: when you say "it brings enormous benefits to a huge class of queries that are common in timeseries", what are you referring to, exactly? I run Cassandra in production and I love its operational simplicity, scale-out design, and write performance. But I think its support for time series is perhaps over-hyped. To me, it seems the only queries you can run in Cassandra is a key lookup (partition key ro…

I am referring to anything that resembles a range query, ie, where you require a bunch of contiguous information queried on a single key. Think "give me all of this person's chat entries from x time to y time", or indeed "give me all this topic's comment entries from x time to y time" (but not both - only one of the above would be efficiently stored - you decide which it would be). Cassandra, as you know, forces a ce…

After some truely horrific experiences with Riak K/V, especially combined with Riak Solr, I won't touch anything from Basho with a ten foot pole. Not sure what's going on over there, but the reality of Riak in production was miles away from what Basho's sales claimed was possible. And yes, we even spent about 4 months working with their tech support. It almost seems that "It's based on Erlang thus it scales" was the entirety of their design work.

I've also worked with Cassandra and have nothing but good to say about it, did what we asked it right out-of-the-box. Datastax was really helpful as well.

--

And I have no affiliation with either Basho nor Datastax, just really happy with one product and completely blown away with the poor performance of the other.

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

#270

Post by erez »

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.

I think this is a recipe for disaster. First, there are basic things that you should do from the get-go, e.g. not using globals. Second, the problem with "eventually I'll do it right" is that by that time, your stuff is out in the open, used by clients and heavily depended upon, and you have no way of refactoring. A company that uses a bad piece of technology will suffer many years before they could replace it.
Post reply on HN