DONT USE AN ORM | Prime Reacts

Recorded live on twitch, GET IN

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))

[vikramkrishnan]

As a grandpa dev, instead of learning 5 interchangeable languages of Algol-60 family, if you are a Jr. Dev. spend time learning:
1. Databases: esp db internals and query optimization
2. Unix/Linux esp the networking stack and file system stuff
3. Get into the details of at least one cloud platform
4. Learn bash: the number of problems that can be solved by a simple shell script (sed+awk+grep+pipes)
5. The art of writing clearly and concisely.

[milesrout]

The engagement tactic of mispronouncing SQL to get people to correct you is genuinely funny.

[EvanBoldt]

All we really want from an ORM is type safety.

[martinvuyk]

Django's ORM has an amazing migration system and schema definition, managing indexes is easy, and you always have the option to use the DB connector and raw dog the SQL query. Flexibility and using different paradigms is the answer. They aren't mutually exclusive

[schwarzenilson]

What I most hate about ORMs is that every ORM has its own API, so you spend a lot of time learning and fighting this API, I prefer to just use SQL, and finding help for SQL is a lot easier than for a specific ORM.

[tylermfdurden]

"I didn't like the ORM library I was using, so I wrote my own ORM"

[WewasAtamans]

My experience of not wanting to use an ORM several times:
You still have to map the returned object to a class of some sorts because it is self-documenting in code and you get intellisense.
Then you want to automate some boilerplate code away and abstract it out a little bit.
Then you want to use the same model for updating data as well because it saves you time.
Next thing you know you have a half-baked ORM of your own making that none else knows how to use.
In my home PHP project i ended up with SOMETHING that looks like a mix of Doctrine and Eloquent.
So now I just slap ORM in from the start.

[MagicMoshroom]

I once used an ORM to bind an existing TERRIBLE DB to a model that was easier to work with. Makes it easier to get back into it after a break, without having to learn the whole DB layout and relations again.

[vzakanj]

Another option is not to go with either ORM or SQL, but use them together.
A textbook example is using CQRS to separate your reads and writes and then using the ORM on the write side and raw SQL on the read side.
This way you can use ORM features that make your life easier for writes (identity map and in-memory cacheing, update detection, easily map complex properties to json columns etc.), and use raw SQL for reads/projections.

Also, some ORMs like EF Core can handle migrations as well.

[steveg]

This was back around 1993 as I recall, and I was brought in to determine why it was taking around 30 seconds per check to print checks. They needed to print thousands of checks per run. Yeah, they had an obvious problem. The only real bottleneck should have been the printing speed of the laser printers themselves, not the data processing.

The first thing I did was to take a look at the database that the information being printed on the checks was coming from. INCREDIBLY, I saw the problem immediately. While the table contained the unique ID of the checks, that field in the table had not been defined as the unique ID and it had no index. I redefined that field in the table, and BAM!, problem instantly fixed.

[RegularTetragon]

I really like Haskell's quasi quoters for this, where you can throw SQL strings into your code with what looks like string interpolation but is actually automatically sanitized

[Soraphis]

"Dual schema dangers" is for me the second most important reason to use django for my applications.
I write me schema once and I'm done (all the "batteries included" is reason no1).
Migrations are also basically provided for free. With django you don't rly thing about having a database attached, you're just working with your objects.

[elhaambasheerch]

"Don't focus on the tools, learn the skill of programming"

One of the best advices I got from a senior mentor of mine, I think this sums it up really well.

[notapplicable]

It always shocks me when I realize some of the shortcuts people take with learning software development. It never occured to me you would use ORMs before you've built applications and grown a healthy distaste for raw doggin SQL.

[jackevansevo]

This guy claims to have experience with ORMs like SQLAlchemy, but statements like "ORMs don't help manage data migration at all" are just plain wrong. I used alembic at multiple jobs and never had issues. Would much rather be doing this than hand rolling migrations with SQL.

[genechristiansomoza]

What's wrong with just using sql? It's only disadvantage is if you move from mysql to postgress for example. There might be difference in syntax. Changing database does not happen all the time though. I prefer writing sql over using orm.

[ClaudioBrogliato]

As a Rails developer I heavily rely on ORM. I actually had to work on a time series oriented DB and boy, I had some of the problems he mentioned, specifically writing queries which rely on window function. When you know SQL a bit you tend to think how you would write the query and then back port it to ORM jargon, which is usually more complicated unless your query has to join and filter tables dynamically given different parameters. Creating reports is where ORMs really suck hard on. If you have to manually select fields, manually ask for distinct results, manually map native functions (no ORM does that for you), think about inner join or left outer join, understand when lazy load nested models helps you not to load the whole db vs when actually eager load them to avoid hundreds of small queries. Last but not least, query debugging... you need to know SQL.

[undrimnir]

That's why I am always rooting for Dapper, which just lets me write an SQL query, get exactly what I need and map it however I want - not forcing me to make 100% the same class. Well, you can kinda argue that Dapper is still an ORM (some call it mini ORM) - but I really appreciate that I can just use SQL instead of learning the API of another library someone decided is cool enough for everyone else to dig into. I still have to write SQL queries anyway when with the schema declaration, to later 'translate' into the library's 'language'.

Oh, and what I also hate so much - when ORM decides to cache which tables are often joined and then add it to every other query I need. Troubleshooting these monsters to find out that this bugger decided I need another inner join which actually removes the data I need is torture.

[datmesay]

The thing with the 14 sql joins was he was trying to use row oriented transactional db to make reports that should’ve been built with at least columns oriented db or dimensional modeling.

[HrHaakon]

I... have actually built parts of an ORM in Java. To handle the simple case of turning a row into an object. It only handles simple cases though.
You can annotate a class with JPA annotations, and tell the api what class you want to turn the rows into, and you get a List<Type> back.

It's really easy to use, and works quite well, but it's also very specific to the current project, is very small and limited, so it's not like it's some sort of Hibernate alternative.
It was made so that raw-dogging SQL could be done more easily, by not having you translate row -> constructor yourself.