4 ms·
ORM is that one layer that fails to abstract anything substantial yet whose existence is intrusive enough to annoy people. The worst example of leaky abstracti
by karmasimida 5y ago
ORM is that one layer that fails to abstract anything substantial yet whose existence is intrusive enough to annoy people.
The worst example of leaky abstraction.
- toast0 5y agoORM makes the easy things easier and the hard things harder. No thanks.
- cageface 5y agoSo choose an ORM that lets you easily drop down to plain SQL in the rare cases where it's necessary and you get the best of both worlds.
- devoutsalsa 5y ago100%. You don’t have to trash your 5 passenger car because you occasionally need to transport 6 people.
- laumars 5y agoYou also don’t buy a 5 seater car to begin with if you already know you need 6 seats.
- deleted 5y ago[deleted]
- laumars 5y agoOr just do away with your ORM entirely and train your staff how to write SQL so they can be effective regardless of the complexity of the queries.
- aidos 5y agoCan you provide some examples? I use sqlalchemy, and the amount of work that it does for me when it comes to handling mutating data is pretty remarkable.
- toast0 5y agoNo real specifics, but I usually run into ORM in the context of I'm the person on the team with experience running MySQL and someone has a slow query. When they're hand built queries, I can usually provide a query or sequence of queries that provides the same data without knocking the server over and it gets put into production within the same day. When they're ORM, it takes days to find the query, and then more days to bend my query sequence to fit the ORM. Sometimes you can add indexes to fix things, but sometimes you really just need to do a simple query followed by a large number of single row queries unioned together, but that doesn't seem to be a feature of the ORMs I've been adjacent to.
- aidos 5y agoYeah, I remember now the pain of using bad orms. That feeling that you know what you want, but it’s going to load the data via configuration that you can’t bend into shape. Sqlalchemy is not that kind of orm. If anything is running slow in production I can find it from the logs and then track it to the code quickly - then you can do any sort of query you want in its place. For me it’s never the orm loading stuff that’s slow, it’s always the more complicated queries we’ve done for reporting or whatever.
- hparadiz 5y agoYou should be using an APM like NewRelic to find those slow queries. If that's not an option you should have a profiler that tracks how long each query took and have it print out the query to a log. Turn it on for a couple hours during peak time and analyze it for slow queries. Also use static table design when applicable and avoid running any query that locks the table up. If the query takes any longer than 500 ms you should be running it as a background job instead.
- toast0 5y agoFinding the bad queries is easy --- mysql has a slow query log since forever. The problem is finding where the query was generated. And convincing the people who wrote the bad query to use a better one. Even without that, show process_list or whatever it is tells you how long the query has been running, with mytop you can just look for anything that's been running for more than a couple screen refreshes and start yelling from there. Usually, when I'm brought in, somebody else designed the tables, poorly, too. There's usually not a whole lot I can do about that, because I don't usually have enough authority to demand a data migration.