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)

woz.posthaven.com

Post reply on HN
Print view View original

271–280 of 360 posts

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

#271

Post by emeraldd »

jcadam wrote: post #258
andybak wrote: post #177

Earlier quoted context omitted.

> ORM: You ask for something and you don't care _how_ its fetched. Try this: > ORM: You ask for something and because you've researched and found a well-written, quality ORM you trust that it will create a sane query. or possibly: > ORM: You ask for something and you accept the tradeoffs vs hand-written queries but you're content that it's the correct tradeoff for your use-case. There's plenty of places for bottlenec…

> ORM: You ask for something and because you've researched and found a well-written, quality ORM you trust that it will create a sane query. Ha. More like: ORM: You've just joined a project already using an ORM selected by an 'architect' that no longer works here. Everything is fine until you start testing your system with a database sufficiently populated with real-world data. You and the DBA spend the next next 6 m…

You have to known when to break free of the ORM. They are great for graphs of CRUD operations and pretty nasty for much of anything else. You may come to a different conclusion depending on the project and dataset of course.

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

#272

Post by da_chicken »

oceanswave wrote: post #240
scarface74 wrote: post #204

Earlier quoted context omitted.

Why is it an either or? EF can do that but then you loose the benefits of a type safe language.

If type safety is so great, why isn’t sql statically type checked

Unless you're talking about SQLite, SQL RDBMSs are both static and strongly typed. The systems typically do allow some implicit type conversions, but type is critical to how a table works.

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

#273

Post by zaphar »

mgkimsal wrote: post #238
zimpenfish wrote: post #229

Earlier quoted context omitted.

If you have to log the generated SQL to understand what's happening, you're already behind the curve. And then what do you do if the ORM is generating junk? If the answer is "use a querybuilder/handcrafted SQL for that one", what's the point of the ORM in the first place?

> And then what do you do if the ORM is generating junk? If the answer is "use a querybuilder/handcrafted SQL for that one", what's the point of the ORM in the first place? The point may be that 98% of the queries are just fine, and you've saved time vs writing by hand, and it may be easier to read/understand for the next people to have to touch the code.

"saved time" at the least optional time to save time. ORM's are a maintenance burden. They obfuscate DB performance behind usually an enormous API surface.

Most software work is maintenance work. Optimizing for initial deployment is shortsighted.

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

#274

Post by zaphar »

scarface74 wrote: post #267
zimpenfish wrote: post #261

Earlier quoted context omitted.

> How often is the ORM generating junk? From what I've seen (couple of home-grown ones, Class::DBI, ActiveRecord), "more often than you want". (I'm willing to admit they may not be class-beating examples. :)

I meant a good ORM. But then again, my definition of a good ORM is an ORM with a language that treats queries as a first class citizen. EF with Linq doesn't really act feel like a separate framework since Linq and Expressions are built into the language.

Those are more of a query framework than an ORM. If that's your bar then most ORMs are going to fail to meet it.

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

#275

Post by [deleted] »

jgraham wrote: post #223
andrewstuart wrote: post #93

Earlier quoted context omitted.

zzzeek - can I take this chance to praise your work on SqlAlchemy. People say there's not enough thanks given to open source developers... here's thanks to you. It's the work of a craftsman.

I'm pretty sure that SqlAlchemy has caused more grief and frustration than any other single library. After all if I didn't know about the excellence of SqlAlchemy, maybe I wouldn't get so cross when I have to do anything non-trivial with the Django ORM ;) Joking aside, SwlAlchemy is very impressive software, and zzzeek deserves all this praise and more. Every time that there's one of these anti-ORM articles I feel li…

[deleted]

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

#276

Post by icebraining »

zimpenfish wrote: post #262
icebraining wrote: post #257

Earlier quoted context omitted.

Security is not just about injection. The ORM we use automatically applies security access rules to the queries, for example.

> The ORM we use automatically applies security access rules to the queries, for example. But surely that's better handled in the database itself?

How would you apply user-configured security rules in the database?

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

#277

Post by tonyedgecombe »

pmontra wrote: post #194
dizzystar wrote: post #191

Earlier quoted context omitted.

Woah, who are you interacting with that not knowing SQL is rare? In my experience, nearly no one knows SQL, and the attitude seems to be that learning it at all is a waste of mental bandwidth. On the other hand, I wonder if knowing none at all is better than knowing a little.

I expect that everybody with a degree knows SQL and I'm realizing that I could be wrong. Maybe sometimes I'm the only one in the room that knows it. I'll check it next time I'm at a technical event leaning on the backend side.

I haven't written very much SQL in my career, there is quite a lot of development that doesn't use it.

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

#278

Post by gwbas1c »

3riverdev wrote: post #73

(Bias: I'm one of the Hibernate ORM committers.) Hibernate (and presumably any ORM) was never intended to be a complete abstraction of anything-SQL. Like others have mentioned here, an understanding of SQL must be had before using an ORM. The ORM is one piece to the puzzle, not a shield to prevent you from having to touch SQL. One pattern I typically use is a take on CQRS: Hibernate for writing/updating/fetching/dele…

I must admit that I've inherited two messes where someone used NHibernate as a replacement for SQL. In both cases, the schema was excruciatingly simple but the code performed excruciatingly poorly.

In once case the project was canceled, in part because it was so late due to the developers not knowing how to use a database. In the other case I put my foot down and removed NHibernate. The schema was so simple that it was just easier to put a few extra minutes into boilerplate code than to put time into learning a new thing.

I'd really like to see a good writeup about the use cases that tools like Hibernate excel at. The problem is that, in both cases, I had to work with a high-level manager who had very bad assumptions about what Hibernate can and can't do.

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

#279

Post by scarface74 »

zkomp wrote: post #260
scarface74 wrote: post #210

Earlier quoted context omitted.

Why would you want to deploy schema changes separately? I would be horrified if someone changed my DB back end without running a full (hopefully automated) set of tests.

The db is separate and the interfaces are defined and the test is for this interface (as part of the schema repository) You dont need an ORM for testing your code... But I think this varies from project to project. How many different applications, in different languages are using your db and do you tolerate downtime?

Why downtime? A developer commits their code, the CI server builds the code, run non database dependent unit test, it gets deployed to the integration environment, automated integration tests get run - fewer in number somewhat slower - it gets deployed to the QA environment and goes through a round of manual testing (sometimes), QA signs off and the build gets deployed to the UAT environment and waits for the business owners sign off, then we turn off the A side of the load balanced farm and it gets to deployed to the A side of the load balanced production servers, it goes through a round of smoke testing (automated and/or manual) and once everyone is satisfied, we make A live, set the load balancer to use side B and deploy to B.

All of the manual sign off steps are integrated with the automated release pipeline. As soon as the required approvals sign off, the next step of the pipeline is done.

Rolling back is just redeploying the previous released version. Branching, source control, etc is also a lot easier when all of your business logic is in code and you don't have to sync up the "right" version of your source control with the right version of your stored procedures.

Of course this is even easier when you're using a NoSql solution where your schema is also defined by your class models. But that's another discussion.....

Of course this doesn't have to just apply to code. With things like Packer and Terraform you can do the same with infrastructure. Automated infrastructure deployment is not my expertise...yet

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

#280

Post by icebraining »

zkomp wrote: post #264
icebraining wrote: post #255

Earlier quoted context omitted.

How would you calculate the average of the sum of three columns (AVG(A + B + C)) which are chosen by the user at runtime?

I personally would write a simple plpgsql stored procedure, but I would not trust user input and only allow a defined set of colums from a defined set of tables. you can have lots of dynamic sql but that might become a rabbithole, just as with an ORM. It sounds like a problem you shouldnt have, now throwing an ORM at such a problem... might lead to even more strange issues down the road...

I personally would write a simple plpgsql stored procedure, but I would not trust user input and only allow a defined set of colums from a defined set of tables.

Sure, you can limit it to a single table and to a certain set of columns e.g. A B C D E. Can you give me an example of a simple plpgsql stored procedure to do this?

you can have lots of dynamic sql but that might become a rabbithole, just as with an ORM

That's not my experience. In a language with good introspection and/or where most entities are first-class, you can do this rather easily. In Python that would take two or three short lines.

It sounds like a problem you shouldnt have

This is a bit of a cop-out :) allowing the generation of simple reports configured by the user is a typical need for us.

Post reply on HN