7 ms·

Why the move away from ORMs? I've certainly banged my head against the wall with them any number of times, but I wouldn't want to give up the compile time chec

by PJDK 12y ago

Why the move away from ORMs? I've certainly banged my head against the wall with them any number of times, but I wouldn't want to give up the compile time checking of queries when I make a db change.

collyw 12y ago
Maybe it depends on your ORM. I use the Django ORM most of the time, and it is great for quick stuff. Say I have to do a bulk update, with a few conditions thrown in. MySQL becomes too much hassle trying to parse the first digit out of a string ,and updating another field with that. A simple script using the Django ORM won't take long to do that and will be far easier than trying to work around MySQL's limited string functions. On the other hand Django's ORM doesn't handle some pretty common cases (conditional aggregates are the first thing that comes to mind). Or complex joins on more than one field. I looks around, and there are ways of hacking these things into the ORM, but they really don't seem worth the bother, when you can use SQL for the query.
- PJDK 12y ago
  Good point. I'm coming from the slightly spoiled .NET/LINQ world so you get (I think) 100% of SQL functionality built in.
  - leereeves 12y ago
    I think learning SQL when you already know LINQ is a bit like learning C when you know C#. Knowing one makes it easier to learn the other, and there's value to understanding the underlying abstraction layer, but you'll avoid using it if you can.
    - rjbwork 12y ago
      I disagree. I love C#/LINQ, but after a couple years of Linq2SQL and EF, I'm back to preferring raw SQL via Dapper. I think it's simply a better programming model.
- jeffasinger 12y ago
  This is why I'm so excited for django 1.8, it introduces the ability to use pretty much any SQL function in aggregates, annotations and order bys, including CASE.
  - collyw 12y ago
    Where can I read about this?
leereeves 12y ago
You can keep an ORM and use SQL only when needed, for example passing raw queries to the ORM, or using a view in the database engine. Or use homegrown database wrapper module(s) and keep compile time checking in the vast majority of the code.
akbar501 12y ago
I moved away from ORMs a while ago b/c I found myself bumping into edge cases too frequently and/or spending too much time trying to figure out how to write complex queries in the ORMs syntax. In general, the move to SQL was initially painful, but is now a breeze. With SQL, I don't have to learn an abstraction that is limited to a specific language. So whether I'm working in Java, Python or JavaScript/Node.js, the SQL is the same. Also, there are numerous technologies that now provide an SQL-like language. For example, learning SQL made it easy to learn CQL (Cassandra), HiveQL, etc.

by PJDK 12y ago

Why the move away from ORMs? I've certainly banged my head against the wall with them any number of times, but I wouldn't want to give up the compile time checking of queries when I make a db change.

collyw 12y ago

Maybe it depends on your ORM. I use the Django ORM most of the time, and it is great for quick stuff. Say I have to do a bulk update, with a few conditions thrown in. MySQL becomes too much hassle trying to parse the first digit out of a string ,and updating another field with that. A simple script using the Django ORM won't take long to do that and will be far easier than trying to work around MySQL's limited string functions. On the other hand Django's ORM doesn't handle some pretty common cases (conditional aggregates are the first thing that comes to mind). Or complex joins on more than one field. I looks around, and there are ways of hacking these things into the ORM, but they really don't seem worth the bother, when you can use SQL for the query.

PJDK 12y ago
Good point. I'm coming from the slightly spoiled .NET/LINQ world so you get (I think) 100% of SQL functionality built in.
- leereeves 12y ago
  I think learning SQL when you already know LINQ is a bit like learning C when you know C#. Knowing one makes it easier to learn the other, and there's value to understanding the underlying abstraction layer, but you'll avoid using it if you can.
  - rjbwork 12y ago
    I disagree. I love C#/LINQ, but after a couple years of Linq2SQL and EF, I'm back to preferring raw SQL via Dapper. I think it's simply a better programming model.
jeffasinger 12y ago
This is why I'm so excited for django 1.8, it introduces the ability to use pretty much any SQL function in aggregates, annotations and order bys, including CASE.
- collyw 12y ago
  Where can I read about this?

leereeves 12y ago

You can keep an ORM and use SQL only when needed, for example passing raw queries to the ORM, or using a view in the database engine. Or use homegrown database wrapper module(s) and keep compile time checking in the vast majority of the code.

akbar501 12y ago

I moved away from ORMs a while ago b/c I found myself bumping into edge cases too frequently and/or spending too much time trying to figure out how to write complex queries in the ORMs syntax. In general, the move to SQL was initially painful, but is now a breeze. With SQL, I don't have to learn an abstraction that is limited to a specific language. So whether I'm working in Java, Python or JavaScript/Node.js, the SQL is the same. Also, there are numerous technologies that now provide an SQL-like language. For example, learning SQL made it easy to learn CQL (Cassandra), HiveQL, etc.