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

What ORMs have taught me: just learn SQL (2014)

wozniak.ca

Post reply on HN
Print view View original

121–130 of 305 posts

Re: What ORMs have taught me: just learn SQL (2014)

#121

Post by toast0 »

StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

> 2. If you're not using an ORM, then you ultimately end up writing one. And doing a far worse job than the people who focus on that for a living. It's no different from people who "don't need a web framework", and then go on to re-implement half of Rails or Spring (without accounting for any CSRF protection). Learning any framework at a professional level is a serious time investment, and many student beginners or quasi-professional cowboys don't want to do that. So they act like their hand-rolled crap is a badge of honor.

As a professional cowboy -- I detest layers; if it's running on my server, I need to support it, even if i didn't write it. An ORM or a web framework adds thousands of lines of codes and usually two or three layers of indirection. It's way less effort to just output some HTML, or just make a database query, than to learn a framework or ORM, and as a bonus it's usually faster too. Also, it's a lot easier to fix slow queries when there's one place that has the whole query (with placeholders where possible -- I may be crazy, but I'm not insane).

Re: What ORMs have taught me: just learn SQL (2014)

#122

Post by dkarapetyan »

rhizome wrote: post #112
dkarapetyan wrote: post #89

Earlier quoted context omitted.

I agree. The problem is that striking that balance is hard. If you go all-in with an ORM then trying to backpedal and figure out at which point you went wrong becomes almost impossible and so now you have a tangled web of ORM queries and no clear path to untangling things.

Sure, but the balance is entirely context-dependent. But hey, I guess this is where all polemics fall down. That said, where is the academic problem in refactoring into the db and decomposing ORM queries into straight SQL where necessary/desired? I'm not a Fortune 500 Systems Architect, but I'm under the impression that this is a fairly straightforward process. Now, management of the systems will necessarily incur ex…

Not so simple. Every big enough place will be a disjointed mess of cross-cutting concerns. The ORM (usually another custom mess on top of some open source thing) ends up being owned by everyone and in effect ends up being owned by no one. So then you end up going around asking each team in turn to fix stuff but each team consists of domain experts and not ORM/SQL experts so no one does anything. So then you bring in ORM/SQL experts but they don't have any domain knowledge so they just chip away at the edges and end up making no improvements and you still are stuck with an ORM nightmare.

The bottleneck in fixing technical things is never the technical stuff. After all, most of this stuff is 70s tech to begin with and the science has been worked out by much smarter people already. The social stuff on the other hand is a different matter entirely and once you're in an ORM quagmire it is impossible to get out.

Re: What ORMs have taught me: just learn SQL (2014)

#123

Post by mixedCase »

craigvn wrote: post #98
PeCaN wrote: post #47

Earlier quoted context omitted.

> If you're not using an ORM, then you ultimately end up writing one. I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from y…

But once you have run the stored proc how do you display it to the user? How do you get the data from the UI to the stored proc to execute? You write some code or it happens by magic? If you write some code, then you have just written an ORM.

In Go I only need to annotate the column name of the struct variable to have it load automagically from DB using just SQL and a little bit of tooling (sqlx). 95% of the convenience of an ORM, none of the problems.

Re: What ORMs have taught me: just learn SQL (2014)

#124

Post by bpicolo »

krapp wrote: post #63
thomasahle wrote: post #52

Earlier quoted context omitted.

> An ORM provides type checking at your application layer This. When composing complex queries, we really want type checking and SQL injection safety.

Unfortunately, ORMs sometimes undermine safety for the sake of convenience. Even ORMs which use parameterized queries (which any sane framework will) may be vulnerable if they build dynamic queries using string concatenation.

No ORM is building query bits from user input with string concat.

Re: What ORMs have taught me: just learn SQL (2014)

#125

Post by kenshaw »

dhd415 wrote: post #113
Animats wrote: post #72

Earlier quoted context omitted.

Marshalling support is useful. SQL result -> struct and struct -> SQL insert code is repetitive to write. Getting fancier than that may be overkill. Marshalling in general needs more compile-time support. Kludges such as Google protocol buffer preprocessors are a fast but clunky way to do it. It would be useful if languages could be given a reference to an SQL CREATE TABLE and could use that information usefully. Fie…

This is the sweet spot of ORMs. A team lead early in my career wrote a tool that read the database schema and generated all the marshaling code at the application layer. We got a degree of type safety and relief from a lot of boilerplate code but no promises of automatically generating SQL or abstracting away the database schema, etc. It worked so well that I wrote one from scratch in another language a decade later…

We released a tool, xo, that generates safe and idiomatic Go code from a database schema that does not make any use of an ORM. I have been meaning to add support for generating code for other languages but have not yet had time to do that. That said, it is very easy and very straightforward to do so.

Check it out: https://github.com/knq/xo

Re: What ORMs have taught me: just learn SQL (2014)

#126

Post by toast0 »

PavlovsCat wrote: post #118
krapp wrote: post #33

Earlier quoted context omitted.

Just use separate statements. You should already know before that point whether or not the request is coming from a logged in user, so to me even the if statements are redundant - have functions or methods that just take parameters for and return the result set of a single SQL query, and figure out which function to call and how valid the results are elsewhere: function getResultsForUser($DB, $user_id) { $query="sear…

Deciding between user or not is the most simple case though. The most monstrous function I have by far considers things such as - is the user logged in, and maybe even owner of the profile we're at? - are we looking at all nodes, or the subnodes/subtree (don't ask) of a node? - do we want to display tags/authors/sources? - are we filtering by tag/author? - what's the display mode: list or full? There might be more to…

This actually feels a lot like localization -- unrolling all the ifs is actually the best way to do it. It feels like you're repeating yourself, but having the whole sentence / query together as one unit gives you the ability to understand the whole context -- often times in a database context, you can omit parts that are useless if you get the full context.

Re: What ORMs have taught me: just learn SQL (2014)

#127

Post by mixedCase »

kpil wrote: post #95
krapp wrote: post #63

Earlier quoted context omitted.

Unfortunately, ORMs sometimes undermine safety for the sake of convenience. Even ORMs which use parameterized queries (which any sane framework will) may be vulnerable if they build dynamic queries using string concatenation.

No ORM will pass queries using string concatenation? (Right? I know nothing about ORMs written in PHP by beginners that don't know SQL if it jumped up and bit them in the ass... But surely no half-decent ORM would concatenate strings to pass arguments?) Anyway. Type safe queries like QueryDSL is extremely nice to work with. But as was mentioned, it all boils down to this: There IS NO silver bullet. You have to learn…

>And the abstractions will leak, and you will be pissed of sometimes, but It Is Worth It because you will save a lot of development time.

Only on some languages. As I mentioned on another comment, on Go I'm very productive using simple database/sql + sqlx. On C# I could die writing mapping boilerplate before getting any business logic done.

Re: What ORMs have taught me: just learn SQL (2014)

#128

Post by Waterluvian »

What django gave us out of the box would have been impossible with SQL in the same timeframe with the resources we had. If we had the luxury to do things properly and fully the first time, we never would have made it to market with our robots.

This isn't to say that one day we won't throw away django or use more SQL. We just had real world schedules to deal with.

Re: What ORMs have taught me: just learn SQL (2014)

#129

Post by manigandham »

PeCaN wrote: post #47
StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

> If you're not using an ORM, then you ultimately end up writing one. I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from y…

> A lot of things people use ORMs for are rather easily solved with stored procedures

More like 1 thing. ORMs are meant to make interfacing through the object/relational impedance mismatch easier and through the regular code in your application. Stored procedures do not come anywhere close to this and are usually the same as just calling any other SQL query as you would when not using an ORM.

If you think any majority of what an ORM is used for can be replaced by stored procedures, then you're not really using an ORM for much at all.

Re: What ORMs have taught me: just learn SQL (2014)

#130

Post by manigandham »

mixedCase wrote: post #123
craigvn wrote: post #98

Earlier quoted context omitted.

But once you have run the stored proc how do you display it to the user? How do you get the data from the UI to the stored proc to execute? You write some code or it happens by magic? If you write some code, then you have just written an ORM.

In Go I only need to annotate the column name of the struct variable to have it load automagically from DB using just SQL and a little bit of tooling (sqlx). 95% of the convenience of an ORM, none of the problems.

That's because sqlx (and the go foundation) are already a basic ORM.
Post reply on HN