DONT USE AN ORM | Prime Reacts

what orms have taught me just learn squeal I've come to the conclusion that for me orms are stop with the for me business everyone always just wants to make everything so palatable for everyone else to hear I've come to the conclusion that orms are more detrimental than a than benefit uh in short they can be used uh to nicely augment working with squeal in a program but they should not replace it some background for the last uh for the past 30 months I've been working with code that has the interface with a post Glee and to some extent squeal light everyone loves that squeal light file testing tell me you don't love squealite file testing tell me you don't because you know it's fantastic you know it is oh what are you doing point it at a local file this little htmx app that I'm building this is just a local file it's just a local file right there that's all it is okay all I have to do jump in here cat out temp contacts uh contacts and good look at that a little square light file right there big fan big fan most of that has been with a squeal Alchemy which I quite like and hibernate which I don't uh let's see I've worked with some existing code and data models as well as designing my own most the data is event based storage timelines with heavy emphasis on creating reports interesting there's like specific databases that are for timeline generation right and and timeline type uh stuff I wonder how well uh I mean I I do a lot of this as well surprisingly enough for the last six months I've been working on a bunch of stuff when it comes to uh Netflix's new initiatives you can go try to find out what Netflix's new initiatives are there's some little there's some little Rumblings out there in the news uh and it always is a huge pain in the ass getting out data and doing it right so I feel for them uh much of this let's see has been written about the object relational and impotence impotence uh mismatch it's hard to appreciate it until you live it uh a new word uh in his well-known essay lays out many uh cogent reasons why orms turn into quagmires in my experience I had the deal directly with a fair number of them entity identity issues dual schema problems data retrieval mechanism concerns and partial object problem I want to talk briefly about my experience with these issues uh and add one of my own okay this is good all right partial objects attribute creep and foreign Keys perhaps the most subversive issue I've had with orms is attribute creep or wide tables you know some of us like wide tables you know I think it's kind of like uh you know I'm just saying just something I've grown to appreciate uh that is tables that uh that just keep accruing attributes as much as I'd like to avoid it sometimes it becomes necessary although things like post Greece histor can help for example a client may be providing you with lots of data that they want attach to reports based on various business Logics furthermore you don't have much insight into this data you're just slapping it around uh this is this in end of itself isn't a terrible thing in a database it becomes a real pain point with an orm specifically the problem starts to show up in any query that uses the entity directly to create the query you may have a hibernate query uh like so on a project query Foo class add restriction on x value this may be fine when Foo has five attributes but becomes a data fire hose when it has hundreds uh this is an equivalent of using select star which usually is saying more than what is intended orms however encourage the use and often make writing precise projections as tedious as they are in squeal I have optimized such queries by adding the appropriate projection and reduce the run time from minutes to seconds all the time was spent translating the database row into Java objects I think he means a column I assume when he says attribute it means column in this case I came here for some fun not PTSD well guess what everybody I remember when I thought because I did squeal for so long and then I was just like you know what I've learned about right or not Mongoose it's like a orn this was years ago and I used Mongoose and I was like this is fun and then about like a week into it I'm like I hate all raps this is like 10 years ago or something crap like that dude I just I I lost I literally lost my uh which leads to another bad experience the pernicious use of foreign keys in orms I've used links between classes are represented in the data model as foreign Keys which if not configured carefully result in a large number of joints when retrieving the object a recent count of one such table in my work resulted in over 600 attributes and 14 joins to access a single object using the preferred query methodology that is crazy what attribute creep and excessive use of foreign Keys show me that in order to use orms effectively you still need to know squeal you do my contention with orms is that if you need to know squeal just use squeal since it prevents you to need to know how non-squille gets translated into squeal dude this is always I swear this this is fantastic I I don't understand a lot of the reasons why people use uh orms I have heard that Prisma has an amazing ability to do um migrations and if that's the case I could totally get why you'd use some sort of migration utility I'm on that team I'm not arguing that but just general use of of orms it's always like you still have to do select star from this table where are these things but instead of doing it in a language that you can simply Google and find out about and read on its performance instead you do the same set of actions but you're doing it in some JavaScript library and some Library we're just like get user with this ID I mean you're already typing squeal just type the squeal right just type the squeal and use sub library that just simply sanitizes inputs and then you don't have to worry about it that's why I do like squeal builders I don't mind squeal Builders right I think that those are okay where you just don't want to do a bunch of it you know what I mean you're not a big fan of it uh sometimes it's easier just to be like um you know whatever I need this joined with that with this win this and you're just like I don't want to know all this squeal okay maybe we can I can I can kind of I can kind of buy squeal Builders because at the end of the day it still turns into a string in which you can expect inspect and understand what you're doing whereas an orm kind of makes that process a bit more opaque you know what I mean if the alternative is a bunch of potential squeal injections the alternative is not that though that is like a false dichotomy and not real the alternative is you use a library that simply sanitizes your input like uh squeal ax in go squealax and go you use the question syntax or whatever and it sanitizes that input for you it just does the right thing or whatever it is right there's like the thing in which you use to prevent yourself from shooting yourself in the foot but you're still writing squeal at the end of the day right not using an orm does not equal squeal injection exactly uh yeah it's just like those two things aren't the same there is no alternative you can use an orm and I'm pretty sure you could figure out how to break it or do something naughty just like if you did uh if you just did raw dog and squeal I'm sure you could also do something naughty and just figuring it out all right let's see yesterday I saw when I saw how to write um a joint and gorm I rage quit and moved all my stuff back to squeal X there you go it's a good move just use squeal X squeal X you will more than likely be happy in two months that you did and you will likely be not refactoring it right uh people seem to like drizzle I saw some drama developing with Drizzle this morning I don't know if you guys saw that but I saw some tweets people looking pretty upset something about I don't know it doesn't it doesn't look good orms often generate n plus one queries absolutely there's some real things there uh data retrieval knowing how to write squeal becomes even more important when you attempt to actually write queries using an orm here's another thing I want to actually throw in here say you have like a portal at your job we have one for our big data I can go on to the Big Data portal and just portal I can just query any table uh I think without pii and I can do a bunch of stuff on it and kind of go through it right that means if I just know squeal I can go there and figure out the query I want to make to retrieve the data and then go and look at all the column definitions figure out which ones have been partitioned in Hive and I can go do all that and then when I figure out the queries I need I can then just bring them directly into my application whereas if you don't have that and you're doing this orm there's no one-to-one translation there I then have to take this squeal query and rewrite it into a library right and if they get a major version update then I'm stuck on this version because they've changed things you know I don't know check one two three yeah uh let's see this is especially important when efficiency is a concern when it comes to data when it comes to squealing efficiency is always a concern 100 of the time uh just because this is like classic bottleneck 101 on your database this is classic how how to add latency and lose friends is I don't know how squeal works but here's my application I built uh from what I've seen unless you really unless if you have a really simple data model that is you never do joins uh you will be bending over backwards to figure out how to get an orm to generate squeal that runs efficiently yeah uh most of the time it's more obfuscated than squealth yep and if you dude it's this is so true especially reading about Prisma and some of the things they're doing with joining and in Rust met like in memory rust joining tables for you programmatically stuff like that great great talk and if you elect to keep the query simple you'll end up doing a lot of work in the code that could be done in the database faster Windows functions are relatively Advanced squeal that is painful to write with orms not writing them into the query likely means you will be transferring a lot of extra data from the database to your application which means all other concurrent requests are going to be affected by that uh in these cases I've elected to write queries using a templating system to describe the tables using the uh orm I get the convenience of an application Level description of the table with direct use of squeal it's a lot less trouble than anything else I've used so far let's go I like this this article is great so far uh dual schema danger so I don't know this one what they're trying to say maybe I don't get it maybe I do this one seems to be one of the uh of those unavoidable redundancies if you try to get rid of it you only make more problems and add excessive complexity the problem is that you end up having a data definition in two places the database and your application if you keep your definition entirely in your application you end up having to write the squeal data definition language ddl with the orm code which is the same complication as writing Advanced queries in the orm if you keep it in the database you'll probably want a representation of the application for convenience and to prevent too much string typing Facts of Life uh facts facts facts I much prefer to keep the data definition in the database and read it into the application it doesn't solve the problem but it makes it more manageable I found that reflection techniques to get data definitions are not worth it and I succumb to managing the redundancy of the data definitions in two places uh you can also have like a build process I've done this before because I was using a mongodb with absolutely no schema and so what I did is I actually had a build process where I would take yesterday's data or whenever I built it I built it like once a week I take that like I take like 15 000 sessions pipe them all in and then build a schema definition based off all the raw dogged Json objects and then updated my schema definition committed it released it internally at Netflix so I always had up-to-date definitions without having to worry about all the other crap that goes with it and so you can kind of have the best of both worlds if you put it into a build process uh and especially if you have squeal if you're using squeal not Mong you will have a definition already there and you will be able to generate those definitions but the damn migration issue is a real kick in the teeth changing the model is no big deal in the application but a real pain in the database after all databases are persistent to whereas application data is not or I'm simply get in the way because they don't help manage data migrations at all I wonder if that's true about uh Prisma everyone I've heard multiple people say prisma's data migration stuff is really nice I work on principle that the database's data definitions aren't things you should manipulate in the application instead manipulate the results of queries so that is the queries are your API to the database so instead of thinking about objects you think about functions which return types thus one is forced to ask should you use an orm for anything but convenience in making queries I just don't even think they make convenience of making queries a drizzle does it well okay um it seems let's see it seems uh to be on it uh can I get a tldr of what he's working on I'm reading about stuff identities dealing with uh entity identities is one of those things that you have to keep in mind at all times when working with orms forcing you to write for two systems while only uh about only have the expressivity of one okay when you have foreign Keys you refer to related identities with an identifier in your application identifier takes on various meanings but usually it's the memory location a pointer in a database it's the state of an object itself these two things don't really get along because you can really only use database identifiers in database okay okay okay okay okay I think I see what he's trying to say here uh he's not really stating like I feel like this is more just like a definitional thing I want to know what what is what is the problem leading to he was talking about how he had like 14 joins that were being made due to foreign Keys uh what this result is having to manipulate the Orem to get a database identifier by manually flushing the cache or doing a partial commit to get the actual database identifier I can't even call this a leaky abstraction because the work leak implies small amounts of content escaping relative to the source huh huh I don't think I strongly get that one I don't think I get it uh I made five microservices uh prod application without any orm for postgreat yeah you did basic you learned how to do basic squeal I'm not a programmer I produce electronic dance music uh I am I gay I don't know that's a question for you to answer I can't answer based on that statement uh yeah yeah what is the uh on about uh something that new uh new art alludes to is the need for developers to handle transactions transactions are dynamically scoped which is a powerful but mostly neglected Concept in programming languages due to the confusion they cause if overuse yeah they're very nice they can be very nice I think he refers to keeping the app data in consistent State relative to the relation between tables yes he means that orms may have forced you to do an insert uh git ID insert B that needs A's ID Etc oh okay yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah I see yeah you have to do these you have to do these uh you have to do these serial operations this leads to a lot of boilerplate code uh with exception handlers and careful consideration of where transaction boundaries should occur it also makes you pass session objects around to any function method that might have to communicate with the database the concept of a transaction translate poorly to applications due to the Reliance on context based on time as mentioned Dynamic scoping is one of the way to use this in a program but it is at odds with lexical scoping okay interesting I agree with that the dominant Paradigm uh thus you must take great care to know about when of a transaction when writing code that works with the database and can make a modularity tricky here's a useful function that will only work in certain contexts okay that's actually a really cool kind of concept to think about I guess never really thought about it is that you have like a time-based scoping versus like a lexical based scoping yeah I can see why that can be difficult no where do I see myself going at this point I'm starting to question the wisdom behind the outright rejection of stored procedures you know I did go harder for stored procedures for a while I did do this for a while I went hard on stored procedures and I can't say it was the worst experience I've had foreign in some sense it was nice there's some things that are very very nice about it granted this was about 12 years ago in my squeal of course and I really liked them I could see why they're they're they're they're they're they're bad in the sense that once you go too far with them once you start bringing in business logic I think you got some you got you got to be careful you got to be really careful like you got to really make sure that your application does what is right to hand off to the stored procedure and avoid goofing up a little too much you know I'm very skeptical of these I'd be careful I'd be careful it sounds uh heretical uh but it may work for my use case and hey the Advent of devops the Divide between the developer and the database administrator are basically non-existent I found myself thinking about the database as just another data type that has an API the queries the queries are return values of some type which are represented as some object in the program by moving away from thinking of it as objects in my application as some as something to be stored in the database the raison for orms I don't know how to say that word I feel like I know that word and I've said it before but now I can't remember how to say it uh and instead thinking of the database as a large and complex data type I found working with the database from an application to be much simpler and wondering why I didn't see it earlier fair I think that's a fair State uh stored procedures are powerful but too much uh but uh too much and your DB will bottleneck and performance and not uh scale yeah Claymore opening yell yeah yeah I worked at a company that did this too and it was too much that's what turned me off to stored procedures but I realized that there's some parts that are good there's some parts that are good I could see myself liking it and disliking at the same time I think it's a true trade-off I think very few times you can say in programming it's a true trade-off I feel like stored procedures could be uh it should listen it should be made clear that I'm not claiming that is how all applications should deal with databases all I'm saying is that it fits into my use case based on the data I'm working with regardless of whether I find that stored procedures aren't actually that evil or whether I keep using templated squeal I do know one thing I won't fall into the orms make it easy trap dude don't fall into that I am fully on this team orems mostly don't make things easy people keep telling me that drizzle orm is the the bee's knees I really would have to see this like I really am in such doubt about it uh they are an acceptable way to represent the data definition but a poor way to write queries in a bad way to store object state if you're using an rdbms uh bite the bullet and learn squeal facts just learn squeal do you guys like a drizzle my current company requires anything more specific than selects to be made in a store procedure that's crazy as well see like weird rules like that are like the death of software engineering I don't get what it is but something about that is just crazy to me here I want to ask this uh do you like what just happened there uh or Rams uh yes orms good only drizzle only uh Prisma uh squeal builders raw Rod raw dog squeal I'm actually curious about this one I forgot keasly I know there's keasley as well but uh this guy argues pretty well for the business logic and the DB okay interesting uh put it on put it on the prime reactor we may uh read it at some raw dog the hot dog yeah I'm just curious yes orms are good A lot of people like orms only drizzle only Prisma okay so a lot of orammers okay I didn't realize this uh squeal Builders we definitely got some squeal Builders I don't think squeal Builders are bad I think that they can be okay but again you're still learning an API just to learn you could just learn squeal instead you know what I mean it's like what's the benefit of going from this table where these values with these columns right I don't know if you're really getting anything out of it do you know what I mean uh raw dog uh raw dog and squeal yeah yeah raw dog and squeal I'm I right now I'm on the raw dog and squeal train okay so it does seem like I'm actually surprised about this that that many people like orms and then more specifically people like only drizzle slash only Prisma I'm actually a little bit surprised about that um uh orams on bad data are the same level as bad data on Roswell yes I mean bad data is bad data we're we're pretending this isn't bad data right you can use uh cases uh where I'll reach but I'll try to avoid it yeah let's see drizzle is not an orm well what's drizzle or M then why do I not see the poll I don't know I built into my own orm in Java okay I built some squeal builders orms are good for simple applications this is how I feel about almost everything in software engineering from every single framework you look at every single thing that shows you how to use it is always showing you in like a really simplified context and it always looks good right you know what I mean and then you use it in bigger things and you hate it foreign if you are concatenating strings dynamically to generate squeal it's time to use a squeal Builder I could I can purchase this that's fine with me I'm on this team if you're doing if if you're doing that it's time to move on to the next level totally agreed with 600 columns let's say well with 600 columns it's bad data it doesn't matter uh if they're using an RM yes yes but no one's arguing that we're all on that team that's crazy but whatever they're doing whatever this person's doing he had a reason to do it and it may not be that easy right you always forget 600 columns we can all agree is bad in SQL but we can also all agree that we've all worked in a production environment in which you accidentally get 600 columns okay bad things just happen okay bad things happen you don't mean it to happen but it just happens sometimes I don't have any thoughts on squilcy that it depends yeah see I still am not sure if it really would benefit from an orm I'm still not sure if it benefits from an orm like camping I I don't know if I agree with this because if it's just transactional stuff then why aren't you just writing select star why are you running so much stuff when you could just be like select column A B C from that I I mean that the most sincere way right and then you obviously just have something in which you grab out a few items like what's the point you know more than four tables create a separate Michael service problem solved isn't is it type safety you still take the squeal and turn it into a type right you still you don't just like like hand around queries right no one hands around a hanging squeal X query for you to scan in the rows you want no you like you create like even in this thing I just create the contacts one at a time right I still deal with objects but there's no need to bring in an entire universe just to create a contact I I always put it close to where I want it where I generate the objects from it's more expensive sometimes you need to update just one column exactly you don't want to select star what you don't want to I am on that team but how do you hydrate my app objects you get them from the database and put them into the objects you do the same thing that the squeal is doing I'll uh people off okay so here's my here's my real take on this is that I find that it's there's this idea that using the thing is hard therefore use something to do all the work for you but at the end of the day you still are almost squealing right you're still doing all the select wear from adding all these things in you're doing a bunch you just know less of what's happening are you actually getting anything out of it is it actually buying you anything like anything at all yeah I do agree this row scan it sucks it it sucks in in squeal X right I I get that I'm on your team it's not like amazing and so you just kind of have to you have to ask yourself why do you abstract and when should you abstract and I'm not saying that's why I'm saying like I generally don't reach for orms because I've had too many bad problems with orms right I think I think orms is what uh is is more of a newbie Tool uh it helps you with auto completion all that you can get Auto completion without an orm right you can get Auto completion just fine oh right move just rated hey thanks raimu all right hey the name is I don't use an orm but I'm sure that there's a case where using an orm is fine I just don't I just personally don't like it uh School Builders are also pretty nice oh Jen just run dog squeal already

Channel: ThePrimeTime

Views: 209,491

Keywords: programming, computer, software, software engineer, software engineering, program, development, developing, developer, developers, web design, web developer, web development, programmer humor, humor, memes, software memes, engineer, engineering, Regex, regexs, regexes, netflix, vscode, vscode engineer, vscode plugins, Lenovo, customer service

Id: bpGvVI7NM_k

Length: 25min 45sec (1545 seconds)

Published: Tue Aug 22 2023