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

251–260 of 354 posts

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

#251

Post by mexicocitinluez »

Kon5ole wrote: post #168
tengbretson wrote: post #100

I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform…

>ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations. That was a surprising take! I know only a few ORM's but it seems they end up just adding another layer of DTO objects that are entirely separate from the domain classes anyway. So best case the ORM is just a detour for a good domain model. Worst case it creates a weird database-contaminated…

> I know only a few ORM's but it seems they end up just adding another layer of DTO objects that are entirely separate from the domain classes anyway.

Entity Framework in particular has come a long way in this regard. Particularly owned & complex entities, value converters, etc.

https://learn.microsoft.com/en-us/ef/core/modeling/

> Worst case it creates a weird database-contaminated domain model that's hellish to maintain.

CQRS is good for this because it forces you into using a different write and read model. My write models are domain objects and my read models are DTOs that feed the UI and via projection I can shape them without issue.

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

#252

Post by jhgb »

Mikhail_Edoshin wrote: post #209
miohtama wrote: post #199

Earlier quoted context omitted.

SQL is pretty shitty language to write modular, reusable and easy to read code.

It solves a hard problem. For example, it completely insulates the sender from the fact that his transaction is just one among many others.

No, database servers solve that problem. That the unnecessarily COBOL-like SQL ended up being the primary interface to them is simply an unfortunate accident of history.

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

#253

Post by inigyou »

iamflimflam1 wrote: post #241

Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …

ultimately, there is no silver shortcut - you just have to write the damn code

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

#254

Post by mexicocitinluez »

Cthulhu_ wrote: post #221
miohtama wrote: post #199

Earlier quoted context omitted.

SQL is pretty shitty language to write modular, reusable and easy to read code.

ORMs often end up defining their own domain-specific language which is neither SQL nor the language itself, so they don't really solve that problem except in the simplest cases.

With the big exception of Entity Framework which relies on LINQ.

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

#256

Post by argentinian »

revetkn wrote: post #59

If you use Java and like to write SQL, check out https://pyranid.com I stopped using ORMs around 2008 because they made the easy problems easier and the hard problems harder. I wanted to just write SQL and exploit all the power the DBMS has to offer instead of fighting with an abstraction layer, so I created Pyranid in 2015 and keep it actively updated.

Is it very similar to the relatively new jdbcClient from Spring framework?

https://www.danvega.dev/blog/spring-jdbc-client

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

#257

Post by bartread »

inigyou wrote: post #253
iamflimflam1 wrote: post #241

Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …

ultimately, there is no silver shortcut - you just have to write the damn code

Yeah, exactly. I think the best approach is always to know SQL and know the ORM.

Most of the time you’ll be able to simply use the ORM, but every so often you’ll inevitably come up against a situation where a custom query gets the job done better, and you’ll still get the benefits of deserialising to objects that the ORM offers.

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

#259

Post by mexicocitinluez »

setr wrote: post #176
nodamage wrote: post #174

People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman: That ORM's absolve you from having to learn SQL. Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you. Furthermore, if your objects are…

The problem with ORMs are 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result 2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently 3. They make simple queries simple, and hard queries absolutely revolting 4. You end up not wanting to use the objects dir…

> 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result

EF Core is provider-specific and also exposes provider-specific functionality.

> 4. You end up not wanting to use the objects directly anyways, so you end up with object-object-relation, needing a mapping layer from your database-object to your business-objects, which also defeats most of the benefits from change-tracking

This just isn't true for EF Core. https://learn.microsoft.com/en-us/ef/core/performance/effici...

> 5. The generated SQL is periodically utterly nuts, so you have to review every generated query anyways

Not universally true either. You only have to review complex queries. If you're making claims about a specific ORM it would be good to mention it as it's not universal.

> 6. You probably dont want to actually use any of the OOP mapping features like inheritance in your DB

Then don't? Since when is inheritance required for ORM-usage?

I have found a lot of the anti-ORM critiques come from either using a crappy ORM or having not used a good one in the last 5 years.

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

#260

Post by simondotau »

iamflimflam1 wrote: post #241

Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …

I think that journey only feels inevitable if you start from the assumption that the application object model is the centre of the system. An alternative journey:

Hmm – I should model the data according to the domain, not according to the shape my application objects happen to want.

Hmm – maybe “related objects” are not things to auto-fetch, but relationships the database engine is already built to handle.

Hmm – now that my schema matches my domain, complex problems can be solved with a few lines of SQL, saving me hundreds of lines of application code.

Hmm – in fact, now I realise that many important operations can be performed without round-tripping the data through application code at all, saving me thousands of lines of application code.

Post reply on HN