Hacker News Reader

Comment by ungzd | Hacker News Reader

He is writing it as if ORMs are only for allowing to do queries without knowledge of SQL syntax (which is weird idea) and for forcing database to fit into OOP mindset.

SQL (in strings) is not composable at all. Your app rarely has fixed set of queries and almost always need to be able to construct 'where' dynamically, add joins, etc. SQL syntax is especially non-composable, because there once was hype to make programming languages imitate natural languages. In this case, ORM is inevitable if you don't want to have rube goldberg machines of string concatenation everywhere.

Non-OO ORMs may be not called "ORM"s but idea is the same. Moreover, Sqlalchemy Core mentioned in article is great example of non-OO ORM: it composes queries and returns result in tuples[1].

[1] http://docs.sqlalchemy.org/en/rel_1_1/core/tutorial.html

View on HN

Yea, I find that one of the primary benefits of Django's orm is query set methods, which allows me to define and compose query fragments. I've rarely worked on a code base whwe you write a query once and then never change it, the queries are constantly changing. If you have these query fragments that can be composed, it's a lot easier to change the resulting query without changing much code.

The composability of ORM queries is a huge benefit to organization and readability -- but not all ORMs handle that well.

The article makes a good point; I never think of an ORM as a replacement for SQL -- it can work in concert with it. A lot of my code is much simpler with an ORM than it would be worth out it and in other places it's much simpler with direct SQL than without it. Both can live together harmoniously.

EXACTLY. You can drop into SQL in many ORMs and you use that sparingly as it is much nastier to maintain nuances when switching between different SQL implementations like MySQL and PostgresQL, for example.

What you're describing is an eDSL (embedded DSL). The syntax of SQL is embedded in the host language, which allows you to use the host language's constructs to compose bits of SQL. It's not 'non-OO ORM' code the developer is writing, it's just SQL with Python syntax. Also I highly recommend SQLAlchemy core!

Another example of this would be Pandas for Python, the code the developer writes looks like Python, but the DSL provided actually translate to Fortran & C. There's also a project called Dask which reimplements the backend for Pandas' DSL to run distributed. I wish there was an equivalent for pyspark :)

You are absolutely right. Besides this, I see two main advantages to ORMs.

1. They isolate the "magic strings" where your code knows about your database schema in one place (the mappings or conventions). Database changes break your app in only one predictable place.

2. They keep junior developers from constructing queries in ways that are vulnerable to SQL injections.

> vulnerable to SQL injections

I put part of that blame on languages. When the wrong thing is so much more natural than the right thing, it's bound to happen.

We use relate (https://github.com/lucidsoftware/relate), a Scala lib.

    sql"SELECT * FROM users WHERE email = $email"

After years and years of no ORM and dozens of junior developers, we've never had a SQL injection bug.

Reply on news.ycombinator.com