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

331–340 of 354 posts

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

#331

Post by nodamage »

ElectricalUnion wrote: post #319
dsego wrote: post #305

Earlier quoted context omitted.

It seems like you are throwing away the baby with the bathwater. I don't think providing 90% of the structure you need is a failed abstraction. And it just doesn't follow that it is pushing you towards sub-optimal structures, not sure where this conclusion comes from. All ORMs I've seen have ways to describe relations between models, even polymorphic types, aggregates, eager loading (to avoid N+1) etc.

> I don't think providing 90% of the structure you need is a failed abstraction. It is, when the "10%" is the actual hot queries that your system will use the most? Code right now "is so cheap". You can provide your favourite LLM with your database schema, and some domain comments, and ask it a query to fetch/update data, and it will generate somewhat sane queries for you. You can then inspect those queries yourself,…

Even if you replace ORM generated queries with hand generated queries or LLM generated queries you're still missing a huge chunk of functionality provided by an ORM.

For my projects I would say that the majority of the value an ORM delivers occurs after the query has returned from the database.

But for some reason everyone focuses on query generation as if it were the only feature of an ORM.

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

#332

Post by sota_pop »

In my experience, boilerplate sql isn’t even something I would consider a big pain point. The biggest challenge (to me) is explicit data contract enforcement across the stack.

I haven’t personally had third-party ORM frameworks succinctly encourage synchronization and help me build against long-term divergence of data models across the stack. “Make it easy to do the right thing and hard to do the wrong thing” still leaves a lot of room for ‘gotchas’ as apps evolve over time.

Finally, I don’t understand the aversion in learning even a bit of sql. As topics go, it’s a very good (maybe even the best, if I were being provocative) effort:payoff ratio. Not sure I’d call myself a sql expert, but am always pleasantly surprised how much functionality is within reach by knowing even the very basics of sql.

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

#333

Post by andersmurphy »

vindex10 wrote: post #108

It's a bit aside, but what i love about ORM frameworks is that they try to find the universal interface to multiple database backends. For basic CRUD it's nice: test on sqlite deploy wherever.

That's partly the problem ORMs. Lowest common denominator that prevents you from leveraging a lot of the power of your actual database.

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

#334

Post by win311fwg »

Arch-TK wrote: post #326
win311fwg wrote: post #297

Earlier quoted context omitted.

ORMs do not inherently build queries. They only provide data transformations between relations (i.e. rows and columns) and objects. Hence the literal name: Object relation mapping. You can absolutely have ORM without query building just as much as you can have query building without ORM. Sometimes ORMs and query builders are combined into a higher order system, such as what is described by the active record pattern.…

Okay, so I have an object like: User { name friends: List posts: List } Let's say we have a "MappedUser" which is derived from this type by this ORM. I now do: user = get_mapped_user() for post in user.friends[0].friends[0].posts { ... } Ignoring "get_mapped_user()" how does our user object work? What happens when I access `.friends`? Does it give me an empty list, because I didn't ask for it? I am not aware of anyth…

> Does it give me an empty list, because I didn't ask for it?

That depends on the rest of your code. If you are using something like the active record or data mapper pattern then it would reach out and fetch more results. If you don't have such mechanics in place then an empty list is possible. We don't have enough information here to say what happens.

> I am not aware of anything that calls itself an ORM which merely does

When your code merely does that, what do you call it?

> ORMs, at their core, try to abstract away something like `user.friends[0].friends[0].posts` more or less into some underlying queries against a relational database.

Active record/data mapper tries to abstract that. ORMs are a necessary piece of active record/data mapper, but one part of a larger system. You also need things like a query builder. ORM alone is not sufficient for these patterns.

> into some underlying queries against a relational database.

Unlikely. SQL is mentioned in the headline for a reason. Nobody uses relational databases in the real world. The only remaining relational database engines that are still maintained really only exist for educational purposes. I understand why you might think a relational database is necessary given that ORM stands for Object Relational Mapping, but as ORM operates on data, not databases, the data can be relational even if the backing database isn't. It simply becomes another mapping step to see them become compatible.

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

#335

Post by Arch-TK »

win311fwg wrote: post #334
Arch-TK wrote: post #326

Earlier quoted context omitted.

Okay, so I have an object like: User { name friends: List posts: List } Let's say we have a "MappedUser" which is derived from this type by this ORM. I now do: user = get_mapped_user() for post in user.friends[0].friends[0].posts { ... } Ignoring "get_mapped_user()" how does our user object work? What happens when I access `.friends`? Does it give me an empty list, because I didn't ask for it? I am not aware of anyth…

> Does it give me an empty list, because I didn't ask for it? That depends on the rest of your code. If you are using something like the active record or data mapper pattern then it would reach out and fetch more results. If you don't have such mechanics in place then an empty list is possible. We don't have enough information here to say what happens. > I am not aware of anything that calls itself an ORM which merel…

> That depends on the rest of your code.

No, I am asking about your hypothetical "bare bones" "ORM" which explicitly _doens't_ have anything beyond "object mapping".

> When your code merely does that, what do you call it?

Certainly not _object_ mapping. It's something between regular "data mapping" and "completely worthless." If the thing you get out of it is not something representing an object from your object model.

> ORM alone is not sufficient for these patterns.

You are talking about a definition of ORM which is at odds with any definition of ORM that I am personally aware of.

Classical ORMs focus almost entirely on providing proxy objects which represent your object model and which back accesses with additional queries.

> Unlikely. SQL is mentioned in the headline for a reason. Nobody uses relational databases in the real world.

SQL is a query language for relational databases. Unless you have another definition for "SQL" or "relational database" which is at odds with common parlance.

> I understand why you might think a relational database is necessary given that ORM stands for Object Relational Mapping, but as ORM operates on data, not databases, the data can be relational even if the backing database isn't. It simply becomes another mapping step to see them become compatible.

While certainly an ORM maps between an object model and a relational model, the fact that this could be done with something other than a relational database seems completely irrelevant to anything in this discussion.

You seem to be taking the term "Object Relational Mapping" splitting it into its constituent parts, looking at the definitions of those terms, and then assuming that the definition for the whole term is just a simple combination of the individual terms.

This is akin to me claiming that OOP doesn't require a programming language or computers, and can merely involve me buying or otherwise procuring a bunch of things (objects) and then setting them up (programming) in the form of a Rube Goldberg machine in order to perform calculations.

My earlier statements regarding the example code existed to point out that the mere act of taking some relational data and somehow converting it to objects in your object model is not "mapping" in any meaningful sense because the resulting objects would be incomplete, and in some cases would not even be able to be constructed from arbitrary relational data.

The mere act of instantiating a partial object graph from relational data is _not_ "ORM", in the same sense that writing and calling functions is not functional programming.

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

#336

Post by antonvs »

recursivedoubts wrote: post #112

Why not both? ORMs for the simpler CRUD operations, SQL when it gets a little hectic. The author basically says this in the first paragraph, but the title (and some of the language the author uses) implies that people should just use SQL. It's a reasonable article pointing out some of the annoyances and problems of ORMs (especially in the Java world, where they tend to be overengineered) but there are still a lot of…

Yes, this is the sensible answer.

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

#337

Post by Kinrany »

simondotau wrote: post #243
Kinrany wrote: post #103

Earlier quoted context omitted.

I'd rather take a mess of ad-hoc interfaces. Forcing people to do domain modeling does not go well.

Pretending that domain modelling is optional does not go well.

Sure, but it's better to do no domain modelling than to pretend doing it.

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

#338

Post by frollogaston »

Cthulhu_ wrote: post #236
frollogaston wrote: post #104

Earlier quoted context omitted.

It should be table stakes for any SWEs working on backend, but it's not. The DB and the code directly interacting with it are way more important than anything you're going to write on top. I keep ending up in situations where I'm the only SWE in the room who really knows SQL, let alone proper schema design, and I have to speak up or else they're going to build an abomination.

But for a lot of people, the focus there is in the "write on top" layer, because they enjoy it more (I suspect). Constraints etc are tested there. But this is caused by another shift (I didn't experience this firsthand so bear with me); early databases often had multiple clients, nowadays it's often a 1:1 relationship with one application owning the DB. Which makes putting in constraints in SQL feel clunky. The bigge…

You can make a decent DB with minimal constraints or stored procs, meant for regular code to use. The abominations I'm talking about are like, they use an ORM, they use meaningful fields as PKs that end up being non-unique later, or they reinvent the type system by making some tables with a json field that can mean completely different things based on some enum column.

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

#339

Post by mattmanser »

Kon5ole wrote: post #312
mattmanser wrote: post #262

Earlier quoted context omitted.

It's not that your domain is different, it sounds more like you don't know how to use ORMs. ORMs don't have to manage migrations, they don't have to even write into the database. When dealing with a bad database design, it can be a legitimate tactic to use ORMs in read-only mode and have writes still as hand-rolled SQL. You can do database-first ORMs, as well as code-first, where the database design is king, not the…

>It's not that your domain is different You have mixed the posts you are replying to - the domain being different from the database is stipulated here. I was giving examples of how this typically happens, and the reasons are entirely independent of whether or not an ORM is being used. I am fully aware that you can handle any mess using an ORM as well, which is why I was surprised at the original claim that ORM's forc…

No thanks.

DTOs are one of the big code smells of a code base that does little but will be full of boilerplate. As soon as you see an automapper or a folder of DTOs you know you're in for some serious pain.

On the plus side you also know you can reduce the codebase by about 75%.

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

#340

Post by simondotau »

mekoka wrote: post #296
simondotau wrote: post #260

Earlier quoted context omitted.

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…

Using an ORM should not exempt you from designing your schema around the domain. If anyone thinks it's the case they're either using the ORM wrong, or using the wrong ORM, or perhaps creating the wrong ORM. Similarly, designing your schema to match the domain does not necessarily grant you the productivity boons of an ORM. Having (ab)used Postgres with and without ORM, I've never had a situation where the latter impo…

ORMs and schema design are not fully orthogonal. A database schema and an ORM model can be conceptually separated, but in practice they influence each other. And even if you are vigilant, knowing that you'll use an ORM will cause you to obsess about things which satisfy the ORM at the expense of good modelling.

TLDR: Tooling pressure is a design pressure.

Post reply on HN