Hacker News Reader

Comment by cies | Hacker News Reader

My take is...

No one needs an ORM: https://dev.to/cies/the-case-against-orms-5bh4

The article opens with "ORMs have proven to be useful for many developers" -- I believe the opposite is true.

I agree with this as well. I started my career at the height of ORMs. Most software developers were only learning the ORM APIs (which of course all differed significantly) and very few were learning SQL outside of the bare basics.

ORMs, like all abstractions, are a leaky abstraction. But I would argue because of the ubiquity and utility of SQL itself they are a very leaky one where eventually you are going to need to work around them.

After switching to just using SQL in all situations I found my life got a lot simpler. Performance also improved as most ORMs (Rails in particular) are not very well implemented from a performance standpoint, even for very simple use cases.

I can not recommend enough that people skip the ORM entirely.

High five!

Is the proposition in the OP not pretty much what you're suggesting in your blog? They're currently not using the query builder syntax, instead its pretty much "improving on SQL as strings" with a bunch of the other ORM-like benefits (type safety, autocomplete, etc.)

Perhaps saying "ORM" is a bit of a misnomer, but they're discussing the DX ergonomics of an ORM and acknowledging the exact challenges you describe

Yeah it's funny they even mention ORM while at the same offering something that has nothing to do with ORMs at all. Yes, many ORM libraries offer additional tools like migration and querybuiler, but that's not the point of an ORM. ORM maps relation data to your OOP data structures. They completely misused the term entirely, which is kinda surprising.

How do you convert your type-safe native objects to and from the database in a reusable way? If you do anything in a reusable way, you're 95% of the way to an ORM. Or do you just accept that you get back random dictionaries from the database and don't care about type-safety?

You write INSERT and SELECT statements for the object types you want to persist.

What is your concern re: random types popping up? SQLite springs to mind as a prime offender due to not enforcing column types OOTB, but most dialects have rather strong typing.

If we’re talking about mapping UUIDs and datetimes from their DB representations to types defined by the language stdlib, that’s usually the responsibility of the DB driver, no?

I'm talking knowing what the shape of the response and shape of the data going in ahead of time and being consistent. SQL is like a black box in and out. I mainly use Python. For that, it's nice to have things like Dataclasses for DTOs or Pydantic models or some sort of DTO class that has known field names and known types. When you use raw SQL, you lose all that or have to roll it yourself. And at that point, you're most of the way to an ORM or at least the data mapping portion of SQLAlchemy.

Mapping a DB response to a Pydantic model is hardly an ORM.

No, that is exactly what an ORM is, plus mapping it back. Anything around that is additional toolings that no ORM needs to be ORM, but is nonetheless usefull.

Pydantic isn’t an ORM, any more than JSON.stringify() and JSON.parse() are an ORM.

Pydantic knows nothing of your database. It’s schema-on-read (a great pattern that pydantic is well suited for), or serialization, or validation, but not an ORM.

Do you advise then use Pydantic for data mapping to/from raw SQL, to avoid using a full ORM? My thinking is you're almost at an ORM with that method with tools like SQLModel that I'm unsure what the benefit is to the plain Pydantic method.

In one sense you’re right, but (at least in data projects) the goal is a bit different. We’re often reading not only from SQL databases, but also parquet files, CSV, JSON, APIs, piped input from another process’s STDOUT, and so on.

Basically we don’t always know what the future unknown data source we may be reading from, and also the schema of the source might change, but we can define what we expect on the receiving end (in pydantic), and have it fail loudly when our assumptions change.

The nice thing about SQLModel is they're still Pydantic models so you can use them with custom data mappers like parquet, csv, json, etc. I think you make a good point about keeping the data model pure so you're not dependent on a data source. But I think SQLModel largely accomplishes that, and so does SQLAlchemy's declarative dataclass mapping (though I've not used the latter).

> Pydantic serves as a great tool for defining models for ORM (object relational mapping) libraries. ORMs are used to map objects to database tables, and vice versa.

https://docs.pydantic.dev/latest/examples/orms/

This really depends on the quality of the ORM. I used to write Java software, and Hibernate with QueryDSL saved me probably _months_ of typing. And I dare say, produced much nicer-looking code.

And for most of the code, the performance and overheads were negligible. C# with LINQ is even better, it provides strong typecheck for the queries and often has almost zero overhead.

I'm using Go now, and I don't even want to touch any of the available ORMs because they all suck, compared to the state-of-the-art in Java circa 20 years ago.

I think what I just really want is a language that treats sql as a "first class" component in the same way perl treats regexes.

The devil is of course in the details, but it's a nice dream.

Not quite first class citizen, but you might like sqlx. At least it embraces the idea that writing SQL directly is in fact a good idea and helps you to do so safely.

https://docs.rs/sqlx/latest/sqlx/

LINQ? Just throwing it out there; obviously not everybody can or wants to run a C#/.NET stack, but entity framework (core) is about as close as you can get to the perl and regex integration. I think Ruby on Rails gets there too, but I'm not a RoR guy, so I can't comment.

I think linq is the closest anyone has come so far, although it is a dsl with slightly different semantics as I understand.

ActiveRecord, RoR's ORM is the complete opposite.

> a language that treats sql as a "first class" component

pl/pgSQL (or pl/sql in oracle) and variants.

Reply on news.ycombinator.com