Hacker News Reader

Comment by Supply5411 | Hacker News Reader

Outer joins are inherently risky because they make it very easy to put conditions in a place that looks correct (read: passes review) but isn't, and the results are disastrous (information leak).

View on HN

In this case the query doesn't make much sense to me and hopefully wouldn't pass review. If you're only looking up purchases for a single user, why would you be joining on the user table at all? I suppose I could see a bad ORM or query builder somehow come up with a bad query like this.

I disagree, as the previous commenter said it’s not the tool, it’s the user and if you don’t know what you’re doing you’re prone to doing damage. Non trivial amounts of auth are made by “junior” engineers. I find that a lot more disastrous than a potential outer join + where accident *that also requires* the application code to leak the data to the outside world to be damaging *and* the underlying data to be sensitive.

So tools carry the same level of risk if the only way they can do harm is user error, even if that user error is easier to miss by design? I guess I just fundamentally disagree because I think risk analysis is holistic. Is the tool fundamentally correct (free of bugs) and is it easier to misuse.

I'm going to look at an outer join FAR more critically, regardless of who wrote it, because it's easy to mess up the conditions.

The same could be said about clueless programming in general. Tbh I didn’t immediately catch what that query does, because it’s non-regular(?) looking so there’s no quick pattern for it, but it still makes you think what it does actually. And no, there’s no way I could think of putting a filter into right join. It’s a join. It’s like… idk. Being clueless.

Reply on news.ycombinator.com