6 ms·

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 re

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.

deleted 15y ago
[deleted]
ergo14 15y ago
"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.
- jpk 15y ago
  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.)
  - clojurerocks 15y ago
    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.
    - kingkilr 15y ago
      .defer() and .only(), they're right in the list of methods on Querysets: https://docs.djangoproject.com/en/1.3/ref/models/querysets/#defer 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.
      - clojurerocks 15y ago
        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.
        bretthoerner 15y ago
        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/ https://docs.djangoproject.com/en/1.3/ QuerySets: Executing queries | QuerySet method reference
malandrew 15y ago
Django (and Rails)(and their ORM) are easy solutions, but they are solutions that complect and therefore are not simple.
- malandrew 15y ago
  I now have two down votes for this answer. Can someone please explain why this deserved a downvote.
  - mdda 15y ago
    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.
    - malandrew 15y ago
      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
  - paragraft 15y ago
    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 http://www.infoq.com/presentations/Simple-Made-Easy (a thought provoking talk for those who haven't seen it)
    - malandrew 15y ago
      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.

deleted 15y ago

[deleted]

ergo14 15y ago

"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.

jpk 15y ago
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.)
- clojurerocks 15y ago
  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.
  - kingkilr 15y ago
    .defer() and .only(), they're right in the list of methods on Querysets: https://docs.djangoproject.com/en/1.3/ref/models/querysets/#defer 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.
    - clojurerocks 15y ago
      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.
      - bretthoerner 15y ago
        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/ https://docs.djangoproject.com/en/1.3/ QuerySets: Executing queries | QuerySet method reference

malandrew 15y ago

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

malandrew 15y ago
I now have two down votes for this answer. Can someone please explain why this deserved a downvote.
- mdda 15y ago
  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.
  - malandrew 15y ago
    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
- paragraft 15y ago
  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 http://www.infoq.com/presentations/Simple-Made-Easy (a thought provoking talk for those who haven't seen it)
  - malandrew 15y ago
    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.