6 ms·

This article misses the point of the django orm and migration system completly. They are meant to allow for the dev of an ecosystem. This is why you have so m

This article misses the point of the django orm and migration system completly. They are meant to allow for the dev of an ecosystem. This is why you have so many django plugins, and why they are so easy to integrate and play together. This is why it's easy to have a dev envs, tests, signals and api generation with django. It trades performances and flexibility for this. It's nothing more than a classic technical compromise. You may need raw sql later on in your django project. But if you feel like starting with it, just go with flask. Django makes no sense.

tuatoru 6y ago
Many of the points made apply equally to Flask/SQLAlchemy or any other framework (Rails, ...). They optimise the wrong things and decrease security.
- giancarlostoro 6y ago
  > They optimise the wrong things and decrease security. They're not meant to optimize for every edge case, they're meant to be as generic as sanely possible.
- smoe 6y ago
  All of them optimize for different things (E.g. SQLalchemy and Django have very different philosophies), so are they all wrong? What should they focus on instead?
giancarlostoro 6y ago
The other funny thing is how easy it is to write migrations in Python via the RunPython capabilities of the Django ORM you can migrate data over. I've yet to need to write any SQL aside from stored procedures and Database Views. You can even export all the contents of your DB to JSON or YAML and import it in Django, so you probably very well could go from SQLite to MySQL / Postgres if you really wanted to. Edit: The other actually funny thing is, Django doesn't force you to use its own ORM. You can write code that doesn't use its ORM. You can override anything and everything.
- jordic 6y ago
  For me it's too much easy to write them with sql or plpgsql.. and later I can use them from node, rust, go.. or whatever.. for me the dB (the model) it's the source of thruth that will lasts.. independent of the language that interacts with it... Also the problem gets worst if you add to the mix something like elastic search. That it also has it's own schema and it's also has to be migrated..
  - bb88 6y ago
    But now you've got the issue that the code needs to match the DB. Django takes care of this for you. It's really quite nice.
    - jordic 6y ago
      That's the trade-off if you decouple the dB from the web framework you have to take care of both.. :) anyway, I prefer to trust the dB (real data on it) that a bunch of complicated things on the Django side.. (I suspect that happened something similar to me when I started reviewing crazy (shoot your food) class based elaborations..
    - giancarlostoro 6y ago
      You can always tell Django's ORM not to manage any of your data and write all your queries. You can also tell Django to give you the query it generates, tweak it (if / as necessary) and run from there.
      - bb88 6y ago
        But why? Granted if you have super complex queries, sure. But 95-99% of the queries are simple typically.
- rurp 6y ago
  > how easy it is to write migrations in Python via the RunPython capabilities of the Django ORM you can migrate data over. Yes! This functionality is extremely useful in a number of cases and isn't all that discoverable. At least in my experience, devs often don't learn about it until they've spent at least a bit of time working on a Django project. Once you get the (basic) syntax down it's quite handy.
ensignavenger 6y ago
Django is incredibly flexible, even if you decide not to use the ORM, or even to just use part of it and write a lot of raw sql, Django is a great choice. It can still be a great choice.
- jefurii 6y ago
  Or even if you ditch the SQL database entirely and use Elasticsearch or some weird custom back-end.
  - jordic 6y ago
    And then (with elastic) why you will use a synchronous web framework ;)
    - VWWHFSfQ 6y ago
      Synchronous web frameworks have been powering some of the largest websites on the internet for decades. That said, Django is actively working toward async views and ORM. It's happening.
      - ensignavenger 6y ago
        In fact, it was just released a few days ago.
        jordic 6y ago
        Then you still need to upgrade Django.. (had seen so many sprint points spent on it.. :/)
smoe 6y ago
I agree with you but I think Sqlalchemy/alembic do the compromises better than Django ORM With Django I always ended up hitting brick walls and ugly hacks. Whereas Sqlalchemy more easily fit in any use case that I had over the years, mainly because of it having multiple layers of abstraction so I can choose and mix as applicable. Learning curve is a bit steeper i admit. I haven't used Sqlalchemy drop in replacement for Django ORM yet, but would consider it for a future project.
- hogFeast 6y ago
  I think one issue with SQLAlchemy is that, somehow, they are the worst of all worlds. They have multiple ways to run queries (iirc, the "model" way, the non-model way, and the raw way) but it is all the "model" way underneath so you end up with all kind of weird hacks if you don't want to use Python as the source of truth (i.e. if you run a query, have no data model in Python but want to turn the data into a dictionary). It seemed like a very flabby codebase (i.e. they started out doing X, and tried to add stuff on top...lots of classes that appear to do the same thing). The only ORM that I have used that handled more complex stuff well was Jooq (Java). Having your database as the source of truth (and running a script to update Java Objects) works far better than the SQLAlchemy approach. I use Django now for a simple app but I used both Jooq and SQLAlchemy on something more complex (the issue was references to parts of the data models across components), and the former was brilliant (although learning curve) and the latter was just awful. I don't think SQLAlchemy docs are good either (again, started out as X and they just kept adding and adding). That is just my experience. I used Django right now, there are no crazy cross-cutting concerns between components, and it works fine.
  - jordic 6y ago
    That's the nice thing around sqlalchemy, it's a lib, a toolkit.. you can start using it on whatever postgresql schema you found.. Django can't only work if things are done like it wants... You will also use Django for an old legacy PHP project with postgresql? You can use SA for taking on it.
    - 6y ago
neillyons 6y ago
Agree. This article misses the use case of people using third party apps with migrations. For example. The Wagtail content management team can create migrations that can be applied to MySQL and Postgres databases. Not sure if that is possible writing SQL files.

tuatoru 6y ago

Many of the points made apply equally to Flask/SQLAlchemy or any other framework (Rails, ...). They optimise the wrong things and decrease security.

giancarlostoro 6y ago
> They optimise the wrong things and decrease security. They're not meant to optimize for every edge case, they're meant to be as generic as sanely possible.
smoe 6y ago
All of them optimize for different things (E.g. SQLalchemy and Django have very different philosophies), so are they all wrong? What should they focus on instead?

giancarlostoro 6y ago

The other funny thing is how easy it is to write migrations in Python via the RunPython capabilities of the Django ORM you can migrate data over. I've yet to need to write any SQL aside from stored procedures and Database Views. You can even export all the contents of your DB to JSON or YAML and import it in Django, so you probably very well could go from SQLite to MySQL / Postgres if you really wanted to. Edit: The other actually funny thing is, Django doesn't force you to use its own ORM. You can write code that doesn't use its ORM. You can override anything and everything.

jordic 6y ago
For me it's too much easy to write them with sql or plpgsql.. and later I can use them from node, rust, go.. or whatever.. for me the dB (the model) it's the source of thruth that will lasts.. independent of the language that interacts with it... Also the problem gets worst if you add to the mix something like elastic search. That it also has it's own schema and it's also has to be migrated..
- bb88 6y ago
  But now you've got the issue that the code needs to match the DB. Django takes care of this for you. It's really quite nice.
  - jordic 6y ago
    That's the trade-off if you decouple the dB from the web framework you have to take care of both.. :) anyway, I prefer to trust the dB (real data on it) that a bunch of complicated things on the Django side.. (I suspect that happened something similar to me when I started reviewing crazy (shoot your food) class based elaborations..
  - giancarlostoro 6y ago
    You can always tell Django's ORM not to manage any of your data and write all your queries. You can also tell Django to give you the query it generates, tweak it (if / as necessary) and run from there.
    - bb88 6y ago
      But why? Granted if you have super complex queries, sure. But 95-99% of the queries are simple typically.
rurp 6y ago
> how easy it is to write migrations in Python via the RunPython capabilities of the Django ORM you can migrate data over. Yes! This functionality is extremely useful in a number of cases and isn't all that discoverable. At least in my experience, devs often don't learn about it until they've spent at least a bit of time working on a Django project. Once you get the (basic) syntax down it's quite handy.

ensignavenger 6y ago

Django is incredibly flexible, even if you decide not to use the ORM, or even to just use part of it and write a lot of raw sql, Django is a great choice. It can still be a great choice.

jefurii 6y ago
Or even if you ditch the SQL database entirely and use Elasticsearch or some weird custom back-end.
- jordic 6y ago
  And then (with elastic) why you will use a synchronous web framework ;)
  - VWWHFSfQ 6y ago
    Synchronous web frameworks have been powering some of the largest websites on the internet for decades. That said, Django is actively working toward async views and ORM. It's happening.
    - ensignavenger 6y ago
      In fact, it was just released a few days ago.
      - jordic 6y ago
        Then you still need to upgrade Django.. (had seen so many sprint points spent on it.. :/)

smoe 6y ago

I agree with you but I think Sqlalchemy/alembic do the compromises better than Django ORM With Django I always ended up hitting brick walls and ugly hacks. Whereas Sqlalchemy more easily fit in any use case that I had over the years, mainly because of it having multiple layers of abstraction so I can choose and mix as applicable. Learning curve is a bit steeper i admit. I haven't used Sqlalchemy drop in replacement for Django ORM yet, but would consider it for a future project.

hogFeast 6y ago
I think one issue with SQLAlchemy is that, somehow, they are the worst of all worlds. They have multiple ways to run queries (iirc, the "model" way, the non-model way, and the raw way) but it is all the "model" way underneath so you end up with all kind of weird hacks if you don't want to use Python as the source of truth (i.e. if you run a query, have no data model in Python but want to turn the data into a dictionary). It seemed like a very flabby codebase (i.e. they started out doing X, and tried to add stuff on top...lots of classes that appear to do the same thing). The only ORM that I have used that handled more complex stuff well was Jooq (Java). Having your database as the source of truth (and running a script to update Java Objects) works far better than the SQLAlchemy approach. I use Django now for a simple app but I used both Jooq and SQLAlchemy on something more complex (the issue was references to parts of the data models across components), and the former was brilliant (although learning curve) and the latter was just awful. I don't think SQLAlchemy docs are good either (again, started out as X and they just kept adding and adding). That is just my experience. I used Django right now, there are no crazy cross-cutting concerns between components, and it works fine.
- jordic 6y ago
  That's the nice thing around sqlalchemy, it's a lib, a toolkit.. you can start using it on whatever postgresql schema you found.. Django can't only work if things are done like it wants... You will also use Django for an old legacy PHP project with postgresql? You can use SA for taking on it.
  - 6y ago

neillyons 6y ago

Agree. This article misses the use case of people using third party apps with migrations. For example. The Wagtail content management team can create migrations that can be applied to MySQL and Postgres databases. Not sure if that is possible writing SQL files.