Hacker News Reader

Comment by lordlarm | Hacker News Reader

I've come up with the same conclusion regarding the Django ORM, as they have. An excerpt:

I believe our single biggest mistake from a technical side was not reigning in our use Django ORM earlier in our applications life. We had Twisted services running huge Django ORM operations inside of the Twisted thread pool. It was very easy to get going, but as our services grew, not only was this not very performant, and it was extremely hard to debug

Django has in many ways become the industry standard in regards to fast development - but it, as so many other ORMs, does not scale and produces horrible SQL-statements. Also for many applications I find Django to be a huge overkill - and in more recent times I've focused a lot more energy using microframeworks such as Flask and Bottle.

View on HN

"Django has in many ways become the industry standard in regards to fast development - but it, as so many other ORMs, does not scale and produces horrible SQL-statements."

I disagree - many ORM's in python world? Try using sqlalchemy it will put django's ORM to shame, it will build fast good looking queries most of time, and if you have a rare case of something not good enough - you can easly tweak it. Can't say anything about Storm but saying that "industry standard" django ORM is OK because "others have same flaws" is just distorting reality to fit this thesis ;-) Ugly truth is django ORM is not ok and it bites many people when they are at the point where it's real pain to fix this - the more developers are aware of this the better.

I'm in the process of building an api in Django (GeoDjango, actually, with PostGIS). What are the gripes with the ORM and how could it be better? (Not that I'm disagreeing; I'm curious. I'm not experienced enough to know what makes an ORM okay or not.)

Theres a couple of issues i had with it personally. It doesnt work that well with nosql. Also i found it difficult to customize or do certain things that i wanted to do. Some of them very basic. For example i wanted to only return individual columns rather then all of them. I spent hours looking for how to do this. I finally found out you do .values or .select or something to that effect at the end of your call. Unfortunately i tried this and got errors. So i gave up in frustration.

.defer() and .only(), they're right in the list of methods on Querysets: https://docs.djangoproject.com/en/1.3/ref/models/querysets/#.... Sorry, but it's a bit hard to take this critique seriously, given how trivial it is. I have a list of complaints about Django's ORM that is about a mile long, so don't think I'll defend it blindly, but let's try to stay grounded in reality when we criticize something.

No idea what defers and only are. Actually maybe only was what i was looking for. The django documentation for many things such as this is almost non existent. Some of it is from older versions as well. And im sorry but how is a newbie supposed to find this stuff. Youve probably been working with python and django for a while. Which is great. But when youre just starting and playing around having to spend hours looking simplistic stuff like this up when you have a million other things to do really gets frustrating.

None of your points are coherent or truthful. This seems common among people that run to Node and Mongo.

> The django documentation for many things such as this is almost non existent.

He just linked you to documentation with exactly what you needed, so it surely exists.

> Some of it is from older versions as well.

He linked to the current 1.3 docs.

> And im sorry but how is a newbie supposed to find this stuff.

The second section of the docs is about models, the second heading is all about QuerySets. The link he pasted is literally right in front of you.

https://docs.djangoproject.com/en/1.3/

QuerySets: Executing queries | QuerySet method reference

That mile-long list of complaints is what I'm after. Not to compel you to write a book about it (but if you did, I'd read it :-P), but what are some of those things?

Geo guys learn Django for GeoDjango. I'll try to find the article, but that part of Django is really, really great.

Django (and Rails)(and their ORM) are easy solutions, but they are solutions that complect and therefore are not simple.

I now have two down votes for this answer. Can someone please explain why this deserved a downvote.

Most people don't understand the work "complect" ([kəmˈplɛkt] vb (tr) Archaic to interweave or entwine). They probably (as I did) thought it was a typo for 'are complicated', making your whole comment a tautology. Or perhaps they thought you were trying to start a flame war by mentioning Rails.

I mentioned Rails because Django and Rails are extremely similar as they try to solve the same problem with similar approaches. The differences in how the two work come down to philosophy. Rails trades a lot more simplicity for ease of use with its "convention over configuration" approach. Django chooses more simplicity over ease of use.

If I were to diagram those two and Node.js, I'd say it looks like this:

Easy <---------------------------> Simple

Rails <-------> Django <------> Node.js

Might have helped to linked to the Rich Hickey talk I assume you're borrowing those semantics for "easy" and "complect" from: http://www.infoq.com/presentations/Simple-Made-Easy

(a thought provoking talk for those who haven't seen it)

Yup. It was such a good talk, I assumed it had made the rounds among HNers that I didn't need to link to is. I assumed wrong.

It is a brilliant talk. The only part that he left out of the discussion, but is worthy of a talk in its own right is the notion of the community (formation and characteristics) as one of the artifacts that result from the constructs of a language.

Reply on news.ycombinator.com