Hacker News Reader

Comment by Beltiras | Hacker News Reader

I suppose this tool has it's place in the ecosystem. I just wonder why anyone would use this when there are ORMs ....

EDIT: I'm not saying this is a waste of time from a developer who obviously puts out quality projects. I'm saying I don't see myself using it. I'm most familiar and comfortable with the Django ORM and have overseen a large project with it. There were several raw queries when I took over but once I left it there were none and all the replacement I did was clean ORM queries more performant than their raw SQL predecessors.

View on HN

It's for people like me who do not use ORMs. I also use things like procedures and multiple result sets. I'm downright vulgar these days.

Because not everything is an Object. Not every program uses Objects. OO is only one (an overused one) of several software paradigms.

RDBMS <-> Objects are a poor match. So much so, many pursued NoSQL to find relief from the pain.

Maybe this is just me being so accustomed to my hammers that I solve everything like it was a nail. My toolset involves exactly that: modelling the space of requests with a complete enough relational database that I can find columns and keys for all incoming data. For the occasional tidbit that doesn't fit properly, stick it in the _extra json field.

ORMs are more difficult to use than queries, and they often make them slower. It's lose/lose

They aren't always more difficult.

I am pretty familiar with the Django ORM where you hit limitations fairly early (if you are writing any moderately complex queries). But I still use it for maybe 90% of the stuff I do because that 90% involves pretty simple queries, and it saves a ton of typing, and integrates well with the rest of the Django ecosystem.

Updating data is a good example. I recently split up some database strings into multiple columns. At first I just wrote the SQL to update a joined table. Then I needed to get regexes involved to pull out certain parts of the string. Doing that in SQL gets ugly, and its far simpler just to use the ORM to pull out the data required and operate on it in Python on a loop.

I don't see the ORM as an either / or, but as a complimentary tool to SQL.

I've yet to encounter a query I could not write using the Django ORM effectively.

Not really. Very complex queries are usually quite simple in django, while I'd have to sit down a while to think how to write the raw sql myself.

It does have the overhead of having to learn the ORM, but once you do that, it pays off.

ORMs are pretty terrible for anything to do with analytics or data science, for example.

Really anything that wants to pull all your data back into python is going to be horrible for analytics. What's really needed in this space is something that is smart enough to push most data-intensive operations down to the database and pull only the minimum amount of stuff back to python to do anything that's CPU intensive.

Because maybe an ORM is overkill sometimes (frequently? always?). I frequently find myself trying to figure out how to do something in the ORM "DSL" that's pretty easy (for me) in SQL.

In addition to the array of other correct responses, I'd all stored procedures or functions. They're so much easier to interact with via SQL, if the ORM supports them at all.

https://github.com/GaleDragon/django-storedprocs

If you've already got the SQL handy, this is pretty useful.

Anyone who has ever used ORMs would know the answer :)

One example is if you're using the JSON features of Postgres. ORMs usually are not suited to these kinds of use cases.

Django's ORM has the JSONB and features from HSTORE for PostgreSQL.

> Django's ORM

That's the catch right there.

Peewee orm supports json, jsonb, hstore, arrays, full text search, server side cursors...

Because one tool never fits all situations.

Because doing something as simple as `select sum(length(content)) from app_comment;` in Django ORM is not possible.

You can still use SQL from the Django ORM.

Exactly, using .raw

It's possible with the ORM, but much more complicated than the SQL you intend to get:

AppComment.objects.annotate(content_len=Length('content')).all().aggregate(Sum('content_len'))

https://docs.djangoproject.com/en/1.9/ref/models/expressions...

What is the generated SQL?

`.all()` is completely redundant (it just clones the queryset).

Reply on news.ycombinator.com