6 ms·
You write sql statements? And turn the response into classes by hand in every app you write? Ruby and python have orms too. Am I missing something?
by tayo42 6y ago
You write sql statements? And turn the response into classes by hand in every app you write? Ruby and python have orms too. Am I missing something?
- coldtea 6y agoYou write classes? What is this, 2005? Joking aside, I do write SQL statements (or use a query builder, which is not the same as an ORM). I don't "turn the response into classes by hand in every app I write" however, because the responses are perfectly usable as they are (in a more functional style), and OO is not the best way to model records anyway. I know Ruby and Python have ORMs, ActiveRecord, SQLAlchemy and so on. They're not really needed. Heck, I've read authors of ORMs saying you don't really need one...
- tayo42 6y agoThis seems like a sweeping judgment your making saying don't use orms, or classes. But this seems like just an odd religious take people have so I'm out...
- PostThisTooFast 6y agoyou + are = you're
- whatl3y 6y agoWhile some people are hard lined enough on this that I agree it sort of becomes weird, I can tell you my beef with ORMs comes from being burned before a couple of times by a super inefficient aggregation ActiveRecord did on GROUP BY queries that it 1. not only took a really long time to figure out why a particular page in our app was loading slow but 2. we ended up having to write raw SQL to fix it. I think the answer depends on the type and load/volume of app you're working with combined with the dynamics, size, and skill level of your team(s). I'm extremely comfortable writing, profiling, query planning, and debugging SQL queries. Others aren't, and therefore having an ORM to query data in the DB with the syntax of the language you're using in your projects makes way more sense, if nothing other in order to speed your team up.
- tayo42 6y agoI think the mistake is thinking an orm is actually going let you be free of knowing or caring database fundamentals. That only applies in the most simple cases. An orm has other benefits though.
- scrollaway 6y agoHow much work do you have to deal with if a column gets renamed? Be honest.
- whatl3y 6y ago1. Don't rename your columns, but if you have to 2. project search and replace on $COLUMN_NAME If your column name is a common keyword, variable name, etc. in your code base and it's difficult to find using project search, that's unfortunate, but we organize our backend code and tests in a logical enough way that it's never taken longer than an hour to create a PR to create a migration to rename a column and update all places in code that reference it.
- scrollaway 6y agoRenaming a column is an operation which showcases the weakness in not using an ORM. Other operations of the sort do exist, anything that operates on columns across multiple arbitrary spots in the code. IMO an hour for a change you have so little confidence about is not acceptable when the alternative allows you to do it in a second with full confidence.
- whatl3y 6y agoWhile this is fair and I don't disagree that changing a column name or possibly other schema changes using an ORM and it's subsequent migration scripts is potentially going to be a faster exercise than without one, changing a column name (or any schema change for that matter) in a database in my experience is rare. If you choose to use an ORM for reasons like it might (emphasis on might) be a bit faster and easier to change a column name than without one instead of for other more meaningful people or efficiency-oriented reasons of the day-to-day developer workflow is probably a poor approach. Keep in mind I've installed and used an ORM in projects where the ORM is used only for migrations, but not used in application code and this is absolutely a fine reason to use one imo. But adopting an ORM for migration purposes and forcing or using in application code simply because it's installed isn't necessarily a good approach.