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

391–400 of 654 posts

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

#391

Post by AlphaSite »

Glyptodon wrote: post #162
breatheoften wrote: post #124

Earlier quoted context omitted.

Query builders can be so good at making it easy to work with the database ... the popularity of ORMs over query builders is a really big collective reasoning failure in my opinion. With a good query builder in hand - it is very unclear to me why anyone would ever want to use an orm.

I like query builders but if everything were done with query builders there'd still be an awful lot of DRY pertaining to business logic that needs to go somewhere. Maybe you replace the ORM with some sort of 'results act as ' abstraction, but things like that often work out much better with consistent scaffolding of some sort, which is mostly what successful ORMs seem to be.

This is why I love Sqlalchemy. We use it as half orm, half query builder and it’s pretty great.

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

#393

Post by Rapzid »

qes wrote: post #118
invokestatic wrote: post #27

This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several years now and never ran into any issues. If I need to write a complex query, I can easily write a @Query annotation in HQL and it neatly fits right in to the repository class. I also develop with query logging enabled so I have better understanding of the quer…

> I’m shocked at how many people have issues with ORMs Simple inexperience. I'd bet most of those people are mid-level developers who have used ORMs enough to hit the rough edges but not enough, or with enough independent agency, to have worked through how to play to ORM's strengths while avoiding their weaknesses. People that were given a hammer and are just understanding that their hammer doesn't work very well to…

Reality does seem to paint a very specific picture.. Django; ORM. Rails; ORM.. I think just about every super popular framework either created or has official support for an ORM. Most popular language platforms have a descent enough ORM options. Phoenix? Let's just call Ecto an ORM.

Thinking about projects I'm aware of.. Stack Overflow created an ORM regardless of if they call it "Micro". They created it and people use it. GitLab uses ActiveRecord.. Gogs and Gitea use ORMs that are a bit fringe TBH.. I actually can't think of a large project I've touched that went completely raw dog on the SQL.

I do believe there are instances where using an ORM, or at least all of an ORM, is not the best choice. But to come out and say they should always be avoided? It's interesting how many people are coming in here SO SURE about that position that is seems completely at odds with what the rest of the industry is, objectively, doing. And when pressed their insights into that opinion are so shallow a baby couldn't drown in them. Hmmm.

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

#394

Post by gernak »

scarface74 wrote: post #355
gernak wrote: post #349

Earlier quoted context omitted.

>You can (and should) use them for simple queries. This is not a very compelling argument to use ORMs. It is saying "it makes easy things easier". This doesn't really buy you much value. The simple things are already simple. Bringing in a very large, complicated external dependency to make simple things simpler, is not a good idea. >If you're loading data into objects then you're just creating your own personal ORM a…

Eventually if you’re working with an object oriented language or if you have to convert the result to JSON, you’re going to have to convert one paradigm to another. Unless you’re programming in assembly, everything you do is being converted into another paradigm that is what every compiler and interpreter does.

You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm. When I am using a high level programming language, it is merely helping me do things like manage memory. I am not constantly wishing I could drop down and work with pointers and so on. It is a foundational paradigm that builds on the top of the one before it. ORMs just present a different, incompatible paradigm.

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

#395

Post by stickfigure »

taffer wrote: post #302
fastball wrote: post #284

Earlier quoted context omitted.

What ORM do people use that influences the structure of their database? The ORM I'm currently using the most can do whatever I need with my Postgres DB. Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.

> What ORM do people use that influences the structure of their database? Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. > Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON. Postgres has great JSON support, does the ORM something…

Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that.

This is not true. There's a culture of doing that in demos, but every production shop I've ever been in curates DDL by hand. Flyway is pretty popular.

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

#396

Post by DougBTX »

chii wrote: post #312
pknopf wrote: post #258

Earlier quoted context omitted.

There's a middle ground. Micro ORMs.

A micro ORM is just an ORM, written well and modularly. It isn't a middle ground - it's choosing to use a well written library. A lot of people conflate ORM's leaking because of poor designed library with ORM being a bad abstraction in general.

The informal definition I have of a micro ORM is an ORM without an identity map and without lazy fetching through proxy properties. Are there any more concrete definitions?

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

#397

Post by revscat »

Avamander wrote: post #341
tomtomtom777 wrote: post #236

Earlier quoted context omitted.

What you are saying exactly highlights what the author is missing: That if your application has some logic, you will eventually have to map your database rows to your in memory typed structures. It sucks. Sometimes it sucks less if you map your queries as well, sometimes it sucks less if you stick to SQL and only map your results, sometimes it sucks so much you're better off with a no-sql solution. But when using a r…

Um, PL/PGSQL and et al for stored procedures exist, OOP is optional.

So? Stored procedures suck. There are good reasons they have never seen serious traction and are infrequently used to the point of being irrelevant.

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

#398

Post by sjwright »

oefrha wrote: post #387
sjwright wrote: post #367

Earlier quoted context omitted.

If the object reasoning inherent in ORM design isn’t influencing your structure, either your structures are trivial or you don’t know how to use the full capabilities of your engine yet. ... or both. Both is always a possibility. Welcome to databases.

Most perfectly viable database schemas in the real world are trivial by your definition of trivial. Trivial designs aren’t necessarily bad designs; sometimes quite the opposite. Thanks for the condescension though.

I don't disagree with anything you've said. Though I might raise a very minor objection to the unspoken implication that the "most" database schemas which are currently trivial should be trivial. You're right that trivial designs are very often preferable. But I would hasten to add that when the application calls for data correctness, a bias towards triviality can occasionally manifest as a trade-off between complexity on the application side and complexity on the database engine side.

(As for the condescension, I agree with that too. It was aimed squarely at the GP in the marginal hope that he gets to experience his own tone mirrored back at himself. It might just offer him some insights into perspective.)

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

#399

Post by zbentley »

philwelch wrote: post #308
erik_seaberg wrote: post #301

Earlier quoted context omitted.

A lot of people who believe only one app (or one language) accesses their org's datastore are mistaken. You have to take extreme measures to prevent ad hoc uses from popping up.

Yes, yes, yes. Why is this the case? 1. If you are doing anything interesting, people are going to ask questions about what you are doing, and the best way to answer those questions is going to be by querying your database. 2. One day you might want to rewrite some of your service/s, split them into microservice/s, etc. At that point, there will be a minimum of two services talking to your datastore: the legacy servi…

> One day you might want to rewrite some of your service/s, split them into microservice/s, etc. At that point, there will be a minimum of two services talking to your datastore.

You should not do this. It removes almost all of the benefits of extracting things into a separate service (services should own their data and the only means of accessing it should be via their APIs). That's not utopian; that's one of the main reasons you do a service extraction in the first place.

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

#400

Post by shkkmo »

sjwright wrote: post #383
fastball wrote: post #284

Earlier quoted context omitted.

What ORM do people use that influences the structure of their database? The ORM I'm currently using the most can do whatever I need with my Postgres DB. Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.

ORMs that I've experimented with tend to fall into one of two categories: either they treat the object model as prime, or they treat the relational model as prime. The former almost invariably spurt out inefficient queries, or too many queries, or both. They usually require you to let the ORM generate tables. If you just want to have your object oriented design persist in a database, that's great. The latter almost i…

I think you may have only experienced bad ORMs then?

All an ORM needs is a mapping between database fields and object properties so a good ORM should allow you to separately define a mapping between your object model and relational model so you retain full control of both.

> it encourages you to write too much data manipulation logic in code rather than directly in the database

I find doing too much business logic related data manipulation directly via SQL to be an anti-pattern that creates significant problems with testing and separation of concerns.

ORMs are good at hydrating objects and persisting updates to those objects. Hand writing code to do this is a waste of time.

SQL is good at running reports and performing mass updates an ORM that doesn't allow you to easily do this is bad.

Post reply on HN