Back

@jenniferplusplus it was felt that the ORM we were using was too much, and they wanted to go with something leaner. So yeah I had to map the relations myself. But I can also see what they're saying, Hibernate does feel like an enormous, impenetrable mystery wrapped in an API. I tried debugging it once when I needed to understand what it was doing

@alter_kaker I can't speak to hibernate, but in entity framework, the actual query is just *right there* in my traces. And logs, if I set the log levels for it.

@gallego It's actually extremely fair to ask why we say this about ORMs more than other frameworks. Why is react or spring or aspnet a nearly automatic choice, but when you get to the database suddenly people can only tolerate hand-written sql?

@anthony_steele Dapper is an ORM, it's just light on features

@jenniferplusplus You can call Dapper an ORM if you want, I have heard it called a "Micro ORM".

It was near the right level of features and ceremony as far as I was concerned.

@jenniferplusplus the selling point of ORMs as opposed to the things we'd rather use is mostly that it lets the team include developers who only understand objects and not relations, but we would never want that, that's kind of the worst-case scenario even, because then we're guaranteed to get into problems the team can't get itself out of.

@jenniferplusplus we are all for high level frameworks that encapsulate queries, or even generate them, but those frameworks need to respect the fundamental nature of the data as relational.

@jenniferplusplus also, just to note this, ORMs go back a long way but there's an even more aggressive step that we think got introduced around the time of Rails, which is the idea that your underlying database should be object-shaped not relation-shaped because that speeds up development of user-facing stuff

@jenniferplusplus and, like, yeah, that probably does speed up application development, and if all you want to do is make an application and sell access to it, great, that may even be a reasonable approach. if your database exists to explore some important problem domain, though, it's inappropriately confining.

@jenniferplusplus anyway, as always with this stuff we are careful in how we talk about it. people are not synonymous with the tools they use and we don't think less of anyone for these choices, or for disagreeing with our analysis.

@jenniferplusplus it's important to respect each others' humanity even when there are differences of opinion. that too often gets forgotten in computing, so we say it explicitly

@jenniferplusplus we're against ignoring prior art, for sure

@jenniferplusplus it's also one of those areas where people have a tendency to incorrectly feel that they can do better without actually having any new ideas

plus it's more fun to work on abstract problems than specific ones

@polotek @jenniferplusplus the ORMs we're okay with are the ones that don't get in our way when we care about the structure of the data, yes

@polotek @jenniferplusplus just to make sure we're on the same page, we've run into situations where no popular ORM in a given language allowed multi-column keys, and the developers viewed that as a weird curiosity nobody would care about

@polotek @jenniferplusplus that is not a deficiency in the concept of an ORM, but it's, as we said elsewhere in the replies, a detail-centric thing that people lack the vocabulary to talk about, and that the focus on objects as the most important abstraction tends to make it harder to deal with

@polotek @jenniferplusplus we would like to get to a world where all the pieces of this problem are well understood and easy to learn about. then the discussions might start going better.

@polotek @jenniferplusplus we also do think it's important to keep in mind that not every query builder is an ORM. query building is just one piece of the problem.

@ireneista @jenniferplusplus for sure. I don't think I would argue with anything you've said. Devs love to give away their agency to make things easier on themselves. That's the thing people often come to regret later.

This was my snarky way of saying ORMs are often attractive to people because they don't want to be bothered to learn the power available at their database layer. In fact they actively avoid it.
https://social.polotek.net/@polotek/112798058005744491

@polotek @jenniferplusplus oh ha yes, that's honestly a fair way to put it (in the quoted toot)

@polotek @jenniferplusplus and like, in a sense that's the point of abstractions, yeah. if they don't save us trouble, why do we have them?

for us as a team leader though, we think it would be a mistake to let our reports avoid learning how databases work in the long run, even if it might make tactical sense as a very brief thing

@ireneista @jenniferplusplus I see it a little differently. I see the point of abstractions as enabling us greater leverage to build more complex solutions on top of powerful primitives. Humans can't handle complexity. We have to compartmentalize and abstract. But if we do that enough, we can build amazing things. But abstractions become net negative when they don't leverage all of the underlying primitives and instead start to constrain the solution space.

@ireneista @jenniferplusplus your example about multi-column keys is a good one. If the abstraction doesn't leverage the fact that the database has already solved this, then solving it at the application layer actually becomes harder and is much less efficient. And that's one of the experiences that can result in people generally disliking ORMs. In that case, they remember the abstraction made their lives harder. But it's important to dig into what actually happened.

@polotek @jenniferplusplus as regards the point of abstractions, we have some framing on another topic that we think also applies here. we think that encysting complexity is never sustainable, while engaging with it has a chance to be.

it's the job of a well designed abstraction to figure out what concerns won't go away, and need to be bubbled up

@polotek @jenniferplusplus constraining the solution space, we'd argue, CAN be okay in limited situations - for example, if the full complexity underneath is not relevant to the goals being accomplished. so we don't really think of it in terms of constraints personally, though we see the point

@atax1a @jenniferplusplus how much trouble it causes in practice really depends on a lot of details. some frameworks are much, much better than others and that all hinges on stuff that nobody even really has the vocabulary to talk about properly, let alone explain why one is good and one is bad

@jenniferplusplus @atax1a oh! yes. heh. we didn't have a word for that :) yes, we like that pattern. we note that it potentially hits limitations when you try to put an MVC thing in front of it, but we like it, so it's our view that the upper layers should change as needed to accommodate it.

@ireneista @jenniferplusplus yep! that's pretty much how we work it. :)

@atax1a @jenniferplusplus makes sense then

@Gaelan yes! absolutely

and it's...

we've seen people do this (because yes, like j++ we've seen people reinvent ORMs for their own projects) in a way where they lazy load the fields

and that turns out to be a really bad idea because it has a sharp performance cliff

@Gaelan what we'd be personally enthusiastic about is a formalism that captures the idea that this object is a slice of that one, and can be used in places that only need stuff from inside the slice

@Gaelan this can be done with type classes but it's arduous because you wind up needing one for each column

@Gaelan oh right! structural types, we really need to spend more time with that.

@ireneista yep, and if you use something like kysely your query results come through with the appropriate types as well - which just leaves you with the annoying bookkeeping of listing the required fields in your function signatures and queries

(in my ideal language, the compiler would infer which fields were being read and generate the appropirate query that way, so the fact that you're not requiesting all the fields becomes more or less invisible - I'm not sure how viable that is!)

@polotek it's true and you should say it

@jenniferplusplus @polotek

(I hate ORMs and like databases)
Nah, actually I hate that every time I've looked at using one, I've already done the DB design and the ORM just wants to fight me about it instead of being a nice wrapper that stays out of the way. Last time was a while ago now, so maybe it's not like that these days.