Hacker News Reader

Comment by skrause | Hacker News Reader

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.

View on HN

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.

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

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!

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.

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.

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.

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.

Reply on news.ycombinator.com