Hacker News Reader

This is very important. Any time you build a bike with training wheels, you need to build in a way to take the training wheels off. Otherwise, at some point the solution is to not make faster training wheels, but discard the bike entirely.

Is C training wheels on assembly?

No. But an ORM is training wheels on SQL.

Right, and (most) C compilers let you fall back on assembly if you absolutely must. So my point still holds, even if you do something silly like employ hyperbole on it.

Indeed. I do worry about the level of SQL knowledge that developers have in general these days. Without understanding it - and the relational model (which I'm a big fan of) - it's impossible to optimise the way you use the ORM.

OT but thanks for SQLAlchemy. It's the model ORM in my opinion. It's the only one I've ever used that feels like it respects SQL. When I started working with Python fulltime I spent days reading through the SQLAlchemy source - I learnt a lot from that.

I have no interest in the 'O' or 'M' in an ORM, but I am very interested in a language better than SQL for interacting with SQL-based pseudo-relational datastores. I've found SQLAlchemy to be a pretty good tool in this respect.

If you've already learned SQL and are comfortable using it directly, do you think there is any reason that it'd be wrong to continue doing so?

it's really not as much about the querying (though there is a lot of time-saving automation to be had there) as it is about integrating the data in your object model with the tuples being shuttled to/from the database. Like, at what point do you get sick of writing redundant "INSERT INTO <table>" over and over again? Are there really people who still don't see the time-wasting, code-cluttering repetition in that?

I'm still amazed that there are developers who would rather spend more time maintaining/debugging/optimizing ORM code in a mature app that just learning a simple INSERT statement.

Because in my experience, the "maintaining/debugging" step is almost non-existent (isn't that the point of the ORM?), and the "optimizing" step hasn't been an issue for the traffic our sites get.

> the "maintaining/debugging" step is almost non-existent (isn't that the point of the ORM?)

Nobody can agree on the point of ORMs, which is a large part of the reason why there's so much debate over whether to use them and how. I must say, if their point is to eliminate maintenance and debugging, then they are failing miserably at it.

who would rather spend more time maintaining/debugging/optimizing ORM code

But that's kind of the point- with a decent ORM library there isn't really much work to do.

    model = MyModel.load(id)

Add a new field to your model? It'll handle it. It might even modify the table for you. With raw SQL you'd have to go and edit your UPDATE and INSERT statements each time. Seems like a lot more maintenance/potential debugging to me.

Okay, add a messaging trigger on update and insert between two joined permission tables, without creating a mutating trigger.

SQL is about a lot more than CRUD and tables.

so add a trigger to your tables. How is an ORM getting in the way of that?

SQL is rarely about a lot more than CRUD and tables. I would think that over 95% of the SQL code ever written has been CRUD operations.

ORMs exist to simplify CRUD operations. If you are trying to do something that is a not a CRUD operation then you'd be mad to try and use an ORM to do it.

If you already have a layer of abstraction to your SQL statements, then it can be arguable. But if your are littering SQL statements everywhere, making changes to the database can be more tedious.

Also if you want to support more than one type database, I would use an ORM.

Other people on your team, might not be on the same SQL level as you. E.g. you can create very fast update/bulk/etc. operations directly in your used SQL engine, but then provide some ORM for people not familiar so that they can get access (speed might not be critical to them, just access to the db).

An example - in the game industry we often have technical artists - pretty cool bunch of folks with awesome talents - art (maya, motionbuilder, etc.) and coding (python, mel, C/C++) - these folks are never afraid to step into the dark woods, and would take SQL and learn it as if it was nothing dangerous, but they surely won't mind a good ORM. From what I've learned, they see most of these things as tools.

Any reason it would be 'wrong'? There are few things in software engineering that are universally 'right' or 'wrong', it all depends on context.

There are plenty of people who already know SQL and are comfortable using it, but still prefer to use an ORM though. It's not like ORMs are only used or liked by people who don't know SQL.

Fair enough. Replace "wrong" with "generally considered a suboptimal idea".

Still, 'it depends'. Yeah, there are all sorts of reasons, depending on context (and plenty of people to argue all those reasons).

Personally, I agree with OP that nobody should ever use an ORM as an excuse to not know SQL. You need to know SQL anyway.

So, once we agree on that, your question "Is there any reason to use an ORM if I know SQL" (that's basically what you mean when you phrase it in the inverse "Is there any reason it would be suboptimal to NOT use an ORM", right?) -- basically just boils down to "Is there ever any reason to use an ORM?".

A topic which is basically the equivalent editor/OS war of db-based web development on HN or reddit. Meaning it's an argument that can and does go on forever, and you can find in-depth treatments of in many other threads.

Thank you. I believe my question has been answered, even if I failed at expressing it the way I intended.

> then replacing the ORM entirely with raw SQL,

anyway it is usually never the case. Why would you build a complex app only to tear it appart with going back to raw SQL ?

i'm not talking about SQLAlchemy but often the main problem with ORM is performance. Especially when a orm has its own query language on top of the SQL language ( Like Hibernate or Doctrine ).

A good ORM imho is what you described , something very light but still usefull enough so one doesnt have to do data transformation from rows to objects. How does SQLAchemy fetch related objects ? is it is lazy ? or does it fetch everything when doing a join query for instance.

Anyway thank you for your great work with SQLAlchemy.