4 ms·

I never understand the argument that I shouldn't use an ORM because I "should not be afraid of SQL". No, I don't use ORMs because I'm afraid of SQL. I actually

I never understand the argument that I shouldn't use an ORM because I "should not be afraid of SQL". No, I don't use ORMs because I'm afraid of SQL. I actually really like SQL and I'm good at writing SQL queries. But I still use ORMs very often because they help me with programmatic composability and with avoiding boilerplate. I mostly use SQLAlchemy ORM for CRUD applications. If I need to I can still drop down to SQLAlchemy Core or raw SQL queries, but those are rare cases. When I have to debug something I always just look at the generated SQL queries, most of the time they are actually quite readable.

dorgo 9y ago
Until you do more than just CRUD. And your ORM's performance drop to zero. And you try to improve performance by circumvent your ORM and get bugs you need a week to debug. Because your ORM has a cache and by cirumventing it you introduced a discrepance between code and database.
- pmelendez 9y ago
  I do not know who downvoted but I support this... people don’t believe me but I have seen this exploding in production so many times that is not even interesting anymore
- hackits 9y ago
  When you have a cache, and even a resultset you're going to get discrepancies between your program state and the database state. If you need to maintain one side over the other that is where locking the records come into play. I find it a bit disappointing in the Java world owned currently by Oracle why the they haven't added extensions to the language so I can write bloody SQL statement and PL/SQL procedures naively in the language!
  - NiceGuy_Ty 9y ago
    Eh, not sold on native sql in a programming language. It doesn't take into account the different styles of databases, let alone the different sql dialects. I think it presents a similar problem as Scala's xml literals, which are now seen as language bloat especially since JSON has become popular.
    - hackits 9y ago
      I really don't see this as a major problem. Just have the ability with your compiler to load a external syntax tree for the specific database sql dialect. Then have the ability in the syntax tree to define types that map directly to a type within the language. Easiest approach would just be to resolve the syntax tree to a constant string that is then sent to the database. I don't know why for the vast majority of programming languages they lack a lot of language features that programmer do day in day out eg... text manipulation, xml parsing, json parsing all of which are pretty straight forward and time consuming in languages without multi-line string literals.
- TYPE_FASTER 9y ago
  So far, I've been happy with SQLAlchemy because of the lack of unexpected behavior. It doesn't cache by default. You can call out to stored procedures, or write raw SQL if you want to.
therealmarv 9y ago
This all works at the beginning without doubt and when your application will stay simple and small and has a small userbase. But I've also seen more than once... when your application will get a certain size it is good to remove ORM like SQLAlchemy for real speed improvements.

dorgo 9y ago

Until you do more than just CRUD. And your ORM's performance drop to zero. And you try to improve performance by circumvent your ORM and get bugs you need a week to debug. Because your ORM has a cache and by cirumventing it you introduced a discrepance between code and database.

pmelendez 9y ago
I do not know who downvoted but I support this... people don’t believe me but I have seen this exploding in production so many times that is not even interesting anymore
hackits 9y ago
When you have a cache, and even a resultset you're going to get discrepancies between your program state and the database state. If you need to maintain one side over the other that is where locking the records come into play. I find it a bit disappointing in the Java world owned currently by Oracle why the they haven't added extensions to the language so I can write bloody SQL statement and PL/SQL procedures naively in the language!
- NiceGuy_Ty 9y ago
  Eh, not sold on native sql in a programming language. It doesn't take into account the different styles of databases, let alone the different sql dialects. I think it presents a similar problem as Scala's xml literals, which are now seen as language bloat especially since JSON has become popular.
  - hackits 9y ago
    I really don't see this as a major problem. Just have the ability with your compiler to load a external syntax tree for the specific database sql dialect. Then have the ability in the syntax tree to define types that map directly to a type within the language. Easiest approach would just be to resolve the syntax tree to a constant string that is then sent to the database. I don't know why for the vast majority of programming languages they lack a lot of language features that programmer do day in day out eg... text manipulation, xml parsing, json parsing all of which are pretty straight forward and time consuming in languages without multi-line string literals.
TYPE_FASTER 9y ago
So far, I've been happy with SQLAlchemy because of the lack of unexpected behavior. It doesn't cache by default. You can call out to stored procedures, or write raw SQL if you want to.

therealmarv 9y ago

This all works at the beginning without doubt and when your application will stay simple and small and has a small userbase. But I've also seen more than once... when your application will get a certain size it is good to remove ORM like SQLAlchemy for real speed improvements.