The Only Database Abstraction You Need | Prime Reacts

The obvious solution is to write your own ORM using JDSL. You are welcome.

Well hello there. Appreciate that you took a very charitable take on my video, definitely agree that arguments in the beginning were absolute garbage. I have no idea what I was thinking. Will blame it on being sick for like 2 weeks and just getting blinded from having no interaction with another human in-person, but oh well. In general I try to make people who might not have built that much stuff/have as much computer science background avoid some very easily made mistakes. Thanks for the point about the intro, always struggle with low retention if I try to go slower, but maybe I should try that again. Very fun to hear your commentary from this POV, never thought I'd have someone react to a video I've made. Also, danggggiiit, 8:17, I didn't catch it... Facepalmed so hard when you paused there. that's what I get for not running unit tests :p

The sweet spot for me are simple query-builders that reflect exactly the syntax of the query under the hood, but save you from the pain of fighting with strings. Primary example is squirrel in GO. Once you have to build a ginormous query using a loop, using raw strings quickly ceases to be fun.

Most of the time I see a video called "Don't use X, use Y" it actually should be named "Learn when to use X, and when to use Y" Both approaches are good depending on what you're doing

16:40 In Brasil if your product targets multiple government agencies then abstracting the database might be the cheapest and fastest idea, I've done some projects in that area and agencies always have very specific requirements for ALL tools so you're either lucky or every agency uses a different Database tool.

isThisAcceptablePartner sounds like a passive aggressive cowboy

Well, the whole discussion is completely different if you do 'enterprise' on-prem installable products and clients come in like 'we need it to run with oracle', 'it should run on mysql', 'we use postgres exclusively'. Then you'd be really glad you have the abstraction layer in place.

Our "database team" changes the database every 2 years - we are now at the 5th attempt and since not all databases supported SQL, we are left with a middleman API that supports only "SELECT * FROM WHERE x". Please don't do this to your teammates!

@JP-hr3xq 9 months ago

I'm glad we use EF Core. It's very well thought-out and mostly prevents you from shooting yourself in the foot. But I'd always want developers to first understand SQL before they write LINQ.

@rzyr 9 months ago

In Java there is Spring Data JPA (Hibernate with extra steps), that allows you to write raw ("native") queries if you want; and Spring Data JDBC, that just does the basic CRUD operations like an ORM, but requires you to write the SQL, if you want anything more complicated. I use the first one at work, but the second one is obviously the right choice 80% of the time.

@vitorguidorizzzi7538 9 months ago

right off the bat he says ORMs are a attempt to make SQL obsolete and/or to avoid learning SQL, i mean if youre gonna shit on something you dont like at least be true to it.

@depafrom5277 9 months ago

We don't use ORM's and Query Builders to avoid writing SQL, we use it to avoid the DRY and string interpolation mess raw SQL creates, there are other benefits as well.

@taklamak 9 months ago

A pattern I have heard about in C# is Dapper for queries and Entity Framework for inserts and updates. Although, personally, when I talk to a database, I like to use SQL, and then map it to some struct or class using Dapper.

@RogueAfterlife 9 months ago

Relational database engines are far more optimized than your application depending on an ORM could ever be. I think most devs choose an ORM either out of convenience or they don't choose to segregate their data manipulation statements and query statements. Queries are easily exposed to applications by constructing views in the db. Commands are implemented as any other language does-- a procedure.

@abulaman8713 9 months ago

Django's inbuilt orm does the queries lazy and definitely has literally every feature he said orms don't. Migrations are actually so smooth. Allows transaction, and locking too. Allows prefetching if you dug yourself into a relational pit.

@wdavid3116 8 months ago

A student in the Web application security course I used to teach was doing a SELECT * and then writing all kinds of looped conditions to filter out the data he actually wanted, running into all kinds of bugs and I said "if only there were some sort of domain specific language specifically designed to do this." SQL really is not hard and it is amazing what people will do to try to avoid learning literally anything.

@InkFPS 9 months ago

Maybe these arguments are more convincing in the wild west of JS ORMs. But in C#, Go, and Java land the ORMs are much more mature and have great adjustability on both in memory options and external query building options when querying. Migrations, sanitization, scaling with dev count, all are good reasons in these languages to be using an ORM too.

@TheEliteFriends 9 months ago

I don't understand the ILADIES part. Could you please explain it?

@crimiusXIII 8 months ago

My new favorite channel. Spicy takes with rich justifications. I'm with you on translating queries you've already composed to ORMs can be difficult. My first Python project years ago was also my first ORM project, because every resource I found on connecting it to a database demanded an ORM. I understood the concept of the ORM, but I hated every second of troubleshooting it.

@felipedidio4698 9 months ago

Prime: gets something wrong Chat: "Netflix btw"