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

Don't use your ORM entities for everything – embrace the SQL

blackparrotlabs.io

Post reply on HN
Print view View original

1–10 of 48 posts

Re: Don't use your ORM entities for everything – embrace the SQL

#4

Post by wuliwong »

I think the correct approach is to understand the SQL that your ORM is using. If you can't have it create the correct query than roll your own. I think most of the trouble people get in with ORMs is not taking the time to understand the SQL that it creates and using it incorrectly as a result.

Re: Don't use your ORM entities for everything – embrace the SQL

#5

Post by Zambyte »

The article mentions database portability as an advantage of ORMs, and I agree - to me that is basically the only real advantage to ORMs. The article also mentions that database portability is not a very compelling advantage, since lots of applications don't actually need that, which I also agree with.

Personally I just pick either PostgreSQL or SQLite depending on my use case (and they're different enough that there is always one obvious choice) and just interface with them directly. Hasn't served me wrong yet.

Re: Don't use your ORM entities for everything – embrace the SQL

#6

Post by mannyv »

I still don't understand why people believe that abstracting away something as important as your data store is a good idea. They quickly run into performance problems that are quite difficult to fix.

It's funny that the same developers that try to avoid vendor lock-in don't realize they've locked themselves into an ORM forever.

Plus, SQL isn't that hard. And as a backend person, you should be able to visualize your data model anyway. A SQL datatbase is just a bunch of planes, for the most part, and the queries are how you intersect them...more or less.

Re: Don't use your ORM entities for everything – embrace the SQL

#8

Post by gigatexal »

wuliwong wrote: post #4

I think the correct approach is to understand the SQL that your ORM is using. If you can't have it create the correct query than roll your own. I think most of the trouble people get in with ORMs is not taking the time to understand the SQL that it creates and using it incorrectly as a result.

Imo software engineers look to the ORM to abstract the declarative set-theory, blah blah of SQL back into the object model they’re familiar with. IMO that’s a dereliction of duty as a developer but it happens and ORMs have gotten pretty good of late. In the Java space the JOOQ team is doing really good work.

In my space of Python SQLalchemy has been the dominate ORM of choice and I hated it but without putting out a better product I have just decided to work around it or adapt.

But if I can I use raw SQL where possible.

Re: Don't use your ORM entities for everything – embrace the SQL

#9

Post by internetter »

mannyv wrote: post #6

I still don't understand why people believe that abstracting away something as important as your data store is a good idea. They quickly run into performance problems that are quite difficult to fix. It's funny that the same developers that try to avoid vendor lock-in don't realize they've locked themselves into an ORM forever. Plus, SQL isn't that hard. And as a backend person, you should be able to visualize your d…

We use Kysely[0], which is a nice balance. The code you write in Kysely translates 1:1 into SQL, which means there's very little perf left on the table, but we get an interface that's automatically typed, type safe, and works well with our js language tools.

[0]: https://kysely.dev/

Post reply on HN