6 ms·

In my 8 years of working on large Python codebases, I think the Django ORM is one of the best pieces of software I've had the joy of using. I often recommend it

In my 8 years of working on large Python codebases, I think the Django ORM is one of the best pieces of software I've had the joy of using. I often recommend it independent of the rest of Django (e.g. to people building Flask apps that need an ORM+migrations). Especially when working on a team with many junior developers who don't know SQL (myself included in the early days), the Django ORM has been a shining beacon of reliability and consistency allowing us to do complex database schema changes without ever having to worry about messing them up or not being able to revert our changes. I don't think I can say the same for any other ORM I've worked with, in particular I have really bad memories of trying to match Django's migration reliability and flexibility using SQLAlchemy + Alembic. Also in regards to switching databases, the ability to swap out PostgreSQL for SQLite on smaller projects without having anything break is a feature I've relied on several times, and I'm extremely grateful maintaining that clean break in the layers of abstraction was prioritized by the Django team. Obviously the author of this article has had different experiences (and has considerable authority in this field), but I caution that their experiences are not universal among Python devs.

VWWHFSfQ 6y ago
> the ability to swap out PostgreSQL for SQLite on smaller projects without having anything break is a feature I've relied on several times Absolutely. Take the extra minute to add a natural key to your Django models and now you can do amazing things like dumpdata from your Prod or Staging database and then loaddata into your local sqlite database for dev. I've never had to run Postgres on my laptop for developing. As long as your CI tests use your production database server type then you don't have to worry about subtle differences between developing locally with sqlite and deploying on another RDMS.
- jordic 6y ago
  That's really a so bad practice, a big code smell.. how you test all the dB logic, with a different dB? Constraints, indexes, tsvs..
  - VWWHFSfQ 6y ago
    > As long as your CI tests use your production database server type
    - bb88 6y ago
      And give the dev the ability to switch out to a different database if needed. Thankfully, in Django it's just a config switch. But for 99% of the business logic tests I write, sqlite is fine. Sure you might have an issue with Oracle, but for day to day stuff, sqlite is good enough.
    - jordic 6y ago
      That's because you are not using the power of postgresql.. (if you can test and run locally with sqlite).. are you using transactions, no? Because Django doesn't enforce them O_O
      - VWWHFSfQ 6y ago
        What do you mean Django doesn't enforce them? Are you saying that transaction.atomic doesn't actually run in an atomic transaction?
        jordic 6y ago
        No I'm saying that if you mutate related models and didn't wrap them on a transaction it can leave you (if something fails) on an inconsistent dB state.. this is something it can't happen on sqla
        VWWHFSfQ 6y ago
        Then wrap the things that you want to run in a transaction.atomic. Is there something I'm missing?
        jordic 6y ago
        That's the thing, you need to explicitly run on a transaction.atomic, with sqlalchemy, that's something that just works..
- bb88 6y ago
  This is absolutely true, especially if the dev environment believes that sqlite should be a first class citizen during development of unit tests.
ramraj07 6y ago
One of the things I've had trouble is that sqlalchemy also supports cross db but not completely (I never figured how to do date diff that works between postgres and sqlite). Does django orm help with that? And have you come across any flask+django ORM repos you can point to ?
- nikisweeting 6y ago
  Here's an example with Flask+Django ORM: https://gist.github.com/ChaosJohn/3842014035353d11591ec82f885eeebf https://gist.github.com/ChaosJohn/3842014035353d11591ec82f88...
bastawhiz 6y ago
I came here to post essentially this exact comment. Give me Django with only routing, middleware, the admin panel, and the ORM and I'd be happy. The time I've saved because of these things so I'm shipping code and not writing SQL by hand is astounding. I've made the decision to use Python and Django over other languages and frameworks solely because of the ORM. I honestly can't think of a single other piece of software that has actively saved me as much time.
- choicenotchance 6y ago
  Ditto. In my 6 years of webdev, I've found that Django ORM and South migrations are a match made in heaven, and really made my life easier - and I'm saying this for not basic crud apps with simple tables and such, but for an ecommerce company with: - 140+ tables with queries spanning JOINs across 10-11 tables (for which denormalization btw was done around the time I was leaving to make stuff little less complex and fast) - migrations happening like crazy almost every week due to the amount of features that were getting developed in that time period - migration reverts also happening - easy to manage DBs tables for multi tenant apps using Django admin scripts
- sergioisidoro 6y ago
  > Give me Django with only routing, middleware, the admin panel, and the ORM and I'd be happy. Very much this. I tend to lean towards Flask for building simple APIs. I think it's easier and faster to start a project and get something done. But I always end up missing the admin features and the far superior ORM, and always regret midway that I did not use Django instead.
dandellion 6y ago
The Django ORM is excellent as long as you stick to the well-trodden path. But if you want to squeeze every ounce of performance or you know that the execution plan a query generates is not the best or it's not using the right indexes, it's like wearing shackles. SQLAlchemy on the other hand makes it very easy to do exactly what you need, without even having to drop to writing raw SQL. The way the ORM and the core are structured is the perfect balance of abstraction and control.
- collyw 6y ago
  I'll agree that the Django ORM isn't very good once your queries get moderately complex. But I have been underwhelmed by SQLalchemy having tried it recently. It's not intuitive compared to Django's and in the end for complex query I just ended up in raw SQL anyway - as I would have in Django's ORM.
raverbashing 6y ago
Absolute second this This is more "how to replace your car's stock transmission and cluch for dubious benefits and higher costs" Django works fine out of the box. The example of "needless migrations" are corner cases more than anything and it's fine to have them. It works. They might be useless but if they're correct in the end, that's fine. DB migration is the one of the last places where I will look for performance over risking correctness. And if you really need performance in one specific complex query, Django lets you do raw SQL queries just fine. Number of times I saw this being actually needed (in a big project): One.
MaxBarraclough 6y ago
If you'll forgive a rather insubstantial ramble about a pet-peeve of mine: > many junior developers who don't know SQL Are you really a web developer if you don't even know SQL? Sounds more like an apprentice. You wouldn't call yourself a junior Japanese translator if you didn't speak Japanese. SQL is a basic competency, not an advanced specialist skill.
- esperent 6y ago
  This sounds like gatekeeping to me. Web development is a huge and rapidly expanding industry. You don't need (in fact, cannot) be an expert in all areas. I've been a web developer for quite a few years now. Mostly front end but I do use Django as well. I also do know some SQL so I guess I pass your arbitrary test. However, I can count the number of times I've used SQL in the last five years on one hand, and in each case it was something simple like create a role/database, and I had to Google the commands anyway due to a lack of practice.
  - MaxBarraclough 6y ago
    > This sounds like gatekeeping to me Not really. It isn't right that the software industry use the same title for both an untrained dabbler and for a CS graduate with a year of industry experience. The former is not a developer, they're a student, or an apprentice. The latter has several years of relevant formal education but only a little industry experience. 'Traditional' engineering fields have legally protected terms like Chartered Engineer. I'm not suggesting software development need be that rigid, but I don't think it makes sense to be so inclusive with a title like 'developer' that it tells the reader almost nothing about the person's level of competence. Legally protected terms aren't necessary for this. If you call yourself a junior Japanese translator but you don't speak Japanese, you'll be laughed out of the room by real translators. That's as it should be. > I had to Google the commands anyway due to a lack of practice But your understanding of the underlying concepts (i.e. the relational model) was still there, and that's no small thing. Familiarity with syntax isn't really the point.
  - ehutch79 6y ago
    It's not really gatekeeping. If you're doing any kind of backend work, you need to know how your persistence layer works. You don't need to be an expert, but you need to realize the implications of what you're doing with the ORM. You need to be able to diagnose issues with your database. There is a grey area between 'don't know' and 'expert'. and what the if someone says it's bad that jr devs don't know something, it doesn't mean they need to be an expert.
collyw 6y ago
A lot of people rant about SQL alchemy. I have used it recently and it isn't anywhere close to Django's ORM for ease of use.

VWWHFSfQ 6y ago

> the ability to swap out PostgreSQL for SQLite on smaller projects without having anything break is a feature I've relied on several times Absolutely. Take the extra minute to add a natural key to your Django models and now you can do amazing things like dumpdata from your Prod or Staging database and then loaddata into your local sqlite database for dev. I've never had to run Postgres on my laptop for developing. As long as your CI tests use your production database server type then you don't have to worry about subtle differences between developing locally with sqlite and deploying on another RDMS.

jordic 6y ago
That's really a so bad practice, a big code smell.. how you test all the dB logic, with a different dB? Constraints, indexes, tsvs..
- VWWHFSfQ 6y ago
  > As long as your CI tests use your production database server type
  - bb88 6y ago
    And give the dev the ability to switch out to a different database if needed. Thankfully, in Django it's just a config switch. But for 99% of the business logic tests I write, sqlite is fine. Sure you might have an issue with Oracle, but for day to day stuff, sqlite is good enough.
  - jordic 6y ago
    That's because you are not using the power of postgresql.. (if you can test and run locally with sqlite).. are you using transactions, no? Because Django doesn't enforce them O_O
    - VWWHFSfQ 6y ago
      What do you mean Django doesn't enforce them? Are you saying that transaction.atomic doesn't actually run in an atomic transaction?
      - jordic 6y ago
        No I'm saying that if you mutate related models and didn't wrap them on a transaction it can leave you (if something fails) on an inconsistent dB state.. this is something it can't happen on sqla
        VWWHFSfQ 6y ago
        Then wrap the things that you want to run in a transaction.atomic. Is there something I'm missing?
        jordic 6y ago
        That's the thing, you need to explicitly run on a transaction.atomic, with sqlalchemy, that's something that just works..
bb88 6y ago
This is absolutely true, especially if the dev environment believes that sqlite should be a first class citizen during development of unit tests.

ramraj07 6y ago

One of the things I've had trouble is that sqlalchemy also supports cross db but not completely (I never figured how to do date diff that works between postgres and sqlite). Does django orm help with that? And have you come across any flask+django ORM repos you can point to ?

nikisweeting 6y ago
Here's an example with Flask+Django ORM: https://gist.github.com/ChaosJohn/3842014035353d11591ec82f885eeebf https://gist.github.com/ChaosJohn/3842014035353d11591ec82f88...

bastawhiz 6y ago

I came here to post essentially this exact comment. Give me Django with only routing, middleware, the admin panel, and the ORM and I'd be happy. The time I've saved because of these things so I'm shipping code and not writing SQL by hand is astounding. I've made the decision to use Python and Django over other languages and frameworks solely because of the ORM. I honestly can't think of a single other piece of software that has actively saved me as much time.

choicenotchance 6y ago
Ditto. In my 6 years of webdev, I've found that Django ORM and South migrations are a match made in heaven, and really made my life easier - and I'm saying this for not basic crud apps with simple tables and such, but for an ecommerce company with: - 140+ tables with queries spanning JOINs across 10-11 tables (for which denormalization btw was done around the time I was leaving to make stuff little less complex and fast) - migrations happening like crazy almost every week due to the amount of features that were getting developed in that time period - migration reverts also happening - easy to manage DBs tables for multi tenant apps using Django admin scripts
sergioisidoro 6y ago
> Give me Django with only routing, middleware, the admin panel, and the ORM and I'd be happy. Very much this. I tend to lean towards Flask for building simple APIs. I think it's easier and faster to start a project and get something done. But I always end up missing the admin features and the far superior ORM, and always regret midway that I did not use Django instead.

dandellion 6y ago

The Django ORM is excellent as long as you stick to the well-trodden path. But if you want to squeeze every ounce of performance or you know that the execution plan a query generates is not the best or it's not using the right indexes, it's like wearing shackles. SQLAlchemy on the other hand makes it very easy to do exactly what you need, without even having to drop to writing raw SQL. The way the ORM and the core are structured is the perfect balance of abstraction and control.

collyw 6y ago
I'll agree that the Django ORM isn't very good once your queries get moderately complex. But I have been underwhelmed by SQLalchemy having tried it recently. It's not intuitive compared to Django's and in the end for complex query I just ended up in raw SQL anyway - as I would have in Django's ORM.

raverbashing 6y ago

Absolute second this This is more "how to replace your car's stock transmission and cluch for dubious benefits and higher costs" Django works fine out of the box. The example of "needless migrations" are corner cases more than anything and it's fine to have them. It works. They might be useless but if they're correct in the end, that's fine. DB migration is the one of the last places where I will look for performance over risking correctness. And if you really need performance in one specific complex query, Django lets you do raw SQL queries just fine. Number of times I saw this being actually needed (in a big project): One.

MaxBarraclough 6y ago

If you'll forgive a rather insubstantial ramble about a pet-peeve of mine: > many junior developers who don't know SQL Are you really a web developer if you don't even know SQL? Sounds more like an apprentice. You wouldn't call yourself a junior Japanese translator if you didn't speak Japanese. SQL is a basic competency, not an advanced specialist skill.

esperent 6y ago
This sounds like gatekeeping to me. Web development is a huge and rapidly expanding industry. You don't need (in fact, cannot) be an expert in all areas. I've been a web developer for quite a few years now. Mostly front end but I do use Django as well. I also do know some SQL so I guess I pass your arbitrary test. However, I can count the number of times I've used SQL in the last five years on one hand, and in each case it was something simple like create a role/database, and I had to Google the commands anyway due to a lack of practice.
- MaxBarraclough 6y ago
  > This sounds like gatekeeping to me Not really. It isn't right that the software industry use the same title for both an untrained dabbler and for a CS graduate with a year of industry experience. The former is not a developer, they're a student, or an apprentice. The latter has several years of relevant formal education but only a little industry experience. 'Traditional' engineering fields have legally protected terms like Chartered Engineer. I'm not suggesting software development need be that rigid, but I don't think it makes sense to be so inclusive with a title like 'developer' that it tells the reader almost nothing about the person's level of competence. Legally protected terms aren't necessary for this. If you call yourself a junior Japanese translator but you don't speak Japanese, you'll be laughed out of the room by real translators. That's as it should be. > I had to Google the commands anyway due to a lack of practice But your understanding of the underlying concepts (i.e. the relational model) was still there, and that's no small thing. Familiarity with syntax isn't really the point.
- ehutch79 6y ago
  It's not really gatekeeping. If you're doing any kind of backend work, you need to know how your persistence layer works. You don't need to be an expert, but you need to realize the implications of what you're doing with the ORM. You need to be able to diagnose issues with your database. There is a grey area between 'don't know' and 'expert'. and what the if someone says it's bad that jr devs don't know something, it doesn't mean they need to be an expert.

collyw 6y ago

A lot of people rant about SQL alchemy. I have used it recently and it isn't anywhere close to Django's ORM for ease of use.