My experience is that ORM are great for avoiding boilerplate IF you already know SQL and don’t consider them as an abstraction layer but as syntax sugar.
What ORMs have taught me: just learn SQL (2014)
541–550 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#542Earlier quoted context omitted.
Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect. The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches. There are two reasons to use the ORM: to not learn SQL, and to generate…
> What we really need is a less shitty version of SQL. My view is the opposite. The power of SQL perpetuates a low-quality software culture. The root issue is a dev culture that can't see past databases. A lot of software design runs like this: (1) translate business patterns into a relational schema; (2) build interactions with that schema; and (3) as that gets harder, use SQL arcana and ORMs and views and stored pr…
> As an alternative, you can derive state from messages.
Bingo!
Unfortunately, if people won't even listen to Alan Kay on this stuff, who will they listen to?
Re: What ORMs have taught me: just learn SQL (2014)
#543This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…
There is a big difference between just writing helper functions to construct SQL and convert data types, and OO-style magical auto-persisted objects. The latter is what I don't like about ORMs but the former is fine. I feel that this is an important distinction to make. As an example, the sqlalchemy docs[0] make this very clear: there's an ORM, but there's also just a core expression library that simply helps you con…
> There is a big difference between just writing helper functions to construct SQL and convert data types, and OO-style magical auto-persisted objects. The latter is what I don't like about ORMs but the former is fine. I feel that this is an important distinction to make.
What's the big difference? Why do you like the former but not the latter? What are the characteristics of the former that makes it distinct from the latter?
Re: What ORMs have taught me: just learn SQL (2014)
#544Earlier quoted context omitted.
Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect. The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches. There are two reasons to use the ORM: to not learn SQL, and to generate…
> What we really need is a less shitty version of SQL. My view is the opposite. The power of SQL perpetuates a low-quality software culture. The root issue is a dev culture that can't see past databases. A lot of software design runs like this: (1) translate business patterns into a relational schema; (2) build interactions with that schema; and (3) as that gets harder, use SQL arcana and ORMs and views and stored pr…
What is the solution then? Are you talking about event sourcing or something different?
Re: What ORMs have taught me: just learn SQL (2014)
#545The "ORM or not" discussion quickly runs off track, because there are so many different ORMs with different features and working on different levels of abstraction.
Recently I have most experience with EF Core (from .net) which does not have the "select * " issue the article describe (you can select whole entities, but you can also project individual columns if you want.) It uses Linq for expressing queries, which means it is more concise end express relational algebra clearer than SQL.
On the other hand I have tried Hibernate, which had such a verbose and cumbersome query builder syntax that it made you long for plain SQL.
Re: What ORMs have taught me: just learn SQL (2014)
#546ORM=Rube Goldberg Machine?
Re: What ORMs have taught me: just learn SQL (2014)
#547I use EF, it helps me with migrations and quick coding.
If I need something extra, I just write the SQL.
All in all, in general, I program much faster than other people who don't have this setup/flow.
I recreated an API someone was working on for 2-3 hours in 9 minutes. This was the "senior" developer of 55 years old.
Including creating the project, creating the migrations, creating the api and a small test.
Re: What ORMs have taught me: just learn SQL (2014)
#548Earlier quoted context omitted.
I’ve never seen a homegrown ORM that was better than a third party one. Whenever there is an issue - and there are always issues - you have to dig into the code, because they are never documented well. There is usually a feature that no one thought about and then you have to make modifications to the custom ORM and you get an even bigger mess.
sort of agree but also: the good third party ORMs started life as homegrown ORMs.
Usually third party stuff has documentation. Home grown stuff often hasn't. And usually better tested.
Re: What ORMs have taught me: just learn SQL (2014)
#549Earlier quoted context omitted.
But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives
An in house solution is almost always better than an external dependency
Lack of testing, lack of documentation and lack of use would be reasons that your claim is usually untrue. You can't Stack Overflow a problem and see if anyone else has encountered it before.
Re: What ORMs have taught me: just learn SQL (2014)
#550Earlier quoted context omitted.
Wow this is great! Very well written README. What just blew me away is the thing with the `JOIN` and the `to_jsonb(authors)`, all with complete typing support for the nested author object. I was actually looking to use a classical, attribute driven query generator (with the sort of chaining API everyone is used to: `tableName.select(...coumns)` etc.) for my next project involving to maybe replace/wrap/rewrite a Rails…
I'm also awed by this! > Just worried about forcing colleagues having to learn SQL instead of using a fancy wrapper. My current team is pretty junior, and I don't see any problem with this. Simple SQL queries are really easy to learn, and complex queries are harder to understand with ORMs than in raw SQL. Moreover, knowing SQL is a useful, marketable skill that will stay relevant for many years to come. If there's so…
I'm also awed by this!
:)
1. Whether `Selectable[]` can be used to query for a subset of fields and how.
Right — this is not (currently) supported. I guess if you had wide tables of large values, this could be an important optimisation, but it hasn't been a need for me as yet.
2. In the `to_jsonb(authors)` example, what would you get back in the `author` field if there were multiple authors with the same `author.id` value? An array of `author.Selectable` objects? This part is awesome but brittle, isn't it?
Multiple authors with the same id isn't going to happen, since id is intended as a primary key, so I'd argue that the example as given isn't brittle. On the other hand, there's a fair question about what happens for many-to-many joins, and since my use case hasn't yet required this I haven't given it much thought.