3 ms·

I don't remember running into any of these issues learning Django or maintaining a Django codebase, but I've written the problems I ran into: https://alexcbecke

I don't remember running into any of these issues learning Django or maintaining a Django codebase, but I've written the problems I ran into: https://alexcbecker.net/blog/django-is-dangerous.html https://alexcbecker.net/blog/django-is-dangerous.html In general, I think Django makes it way too easy to shoot yourself in the foot.

acdha 8y ago
“Validation defined on the model is only enforced on the form” hasn't been true since 2010 when Django 1.2 was released. Most of the database-related discussion shares that pattern of either being factually incorrect (“queries can't use computed columns”), blaming Django for MySQL's many problems or failing to fix problems caused by other code failing to do things like input validation. There's a real discussion about how to handle such issues on large, complex codebase but hiding it behind a clickbait title is not a good way to have that end up anywhere productive.
- alexbecker 8y ago
  You must not have read the section "Validation defined on the model is only enforced on the form". The validations I referenced, e.g. `choices`, are only run in when [`full_clean()`](https://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocs#django.db.models.Model.full_clean https://docs.djangoproject.com/en/dev/ref/models/instances/?...) is called, and it's not called on `save()`--it is usually called through form validation. Regarding computed columns, it looks like the specific issue I ran into repeatedly was [fixed in 1.8](https://docs.djangoproject.com/en/2.0/releases/1.8/#query-expressions-conditional-expressions-and-database-functions https://docs.djangoproject.com/en/2.0/releases/1.8/#query-ex...). I should have been explicit that I was referring to not being able to define such computed columns on the model the way one would a normal column, not to being unable to use `F`-expressions.
  - acdha 8y ago
    > You must not have read the section "Validation defined on the model is only enforced on the form". The validations I referenced, e.g. `choices`, are only run in when [`full_clean()`](https://docs.djangoproject.com/en/dev/ref/models/instances/?... https://docs.djangoproject.com/en/dev/ref/models/instances/?...) is called, and it's not called on `save()`--it is usually called through form validation. In addition to being wrong about whether I read your post, this is a great illustration of what I found tedious while reading it: since that feature was released in Django 1.2, the documentation has been clear about the relationship between save() and full_clean(): https://docs.djangoproject.com/en/2.0/releases/1.2/#model-validation https://docs.djangoproject.com/en/2.0/releases/1.2/#model-va... http://django.readthedocs.io/en/1.2.X/ref/models/instances.html#validating-objects http://django.readthedocs.io/en/1.2.X/ref/models/instances.h... The direct statement of fact you used as a heading simply hadn't been true for years before you wrote your post and it's not helped by little mocking asides such as “Because nobody ever modifies a model instance expect through its form, right?” which are basically restating the reasons why that feature exists in the first place. > I should have been explicit that I was referring to not being able to define such computed columns on the model the way one would a normal column, not to being unable to use `F`-expressions. Strong agreement here. Your post could have been so much more useful if each of the mocking asides had instead been taken as a cue to ask whether it's more likely that so many people have worked on Django for years without noticing such a major flaw or that your understanding of how it was intended to be used is incorrect. Imagine if your post had been something like “Things I learned about Django the hard way” and had covered things like picking safer defaults or updating the docs to more explicitly suggest how validation is intended to work (especially in this age where people use fewer forms and more APIs than a decade ago), or that Django treats the database as the ultimate source of truth so you should approach various things about validation and transactions with that in mind (e.g. strengthening the the wording to make it clear that e.g. get_or_create relies on database integrity checks so you should either set those or religiously use some other strategy). That post could be a DjangoCon talk and it'd get a lot more positive reaction than another angry rant on an internet full of them, especially since people in the community would be likely to share it rather than seeing a big claim which is not correct and closing the tab.
    - alexbecker 8y ago

acdha 8y ago

“Validation defined on the model is only enforced on the form” hasn't been true since 2010 when Django 1.2 was released. Most of the database-related discussion shares that pattern of either being factually incorrect (“queries can't use computed columns”), blaming Django for MySQL's many problems or failing to fix problems caused by other code failing to do things like input validation. There's a real discussion about how to handle such issues on large, complex codebase but hiding it behind a clickbait title is not a good way to have that end up anywhere productive.

alexbecker 8y ago
You must not have read the section "Validation defined on the model is only enforced on the form". The validations I referenced, e.g. `choices`, are only run in when [`full_clean()`](https://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocs#django.db.models.Model.full_clean https://docs.djangoproject.com/en/dev/ref/models/instances/?...) is called, and it's not called on `save()`--it is usually called through form validation. Regarding computed columns, it looks like the specific issue I ran into repeatedly was [fixed in 1.8](https://docs.djangoproject.com/en/2.0/releases/1.8/#query-expressions-conditional-expressions-and-database-functions https://docs.djangoproject.com/en/2.0/releases/1.8/#query-ex...). I should have been explicit that I was referring to not being able to define such computed columns on the model the way one would a normal column, not to being unable to use `F`-expressions.
- acdha 8y ago
  > You must not have read the section "Validation defined on the model is only enforced on the form". The validations I referenced, e.g. `choices`, are only run in when [`full_clean()`](https://docs.djangoproject.com/en/dev/ref/models/instances/?... https://docs.djangoproject.com/en/dev/ref/models/instances/?...) is called, and it's not called on `save()`--it is usually called through form validation. In addition to being wrong about whether I read your post, this is a great illustration of what I found tedious while reading it: since that feature was released in Django 1.2, the documentation has been clear about the relationship between save() and full_clean(): https://docs.djangoproject.com/en/2.0/releases/1.2/#model-validation https://docs.djangoproject.com/en/2.0/releases/1.2/#model-va... http://django.readthedocs.io/en/1.2.X/ref/models/instances.html#validating-objects http://django.readthedocs.io/en/1.2.X/ref/models/instances.h... The direct statement of fact you used as a heading simply hadn't been true for years before you wrote your post and it's not helped by little mocking asides such as “Because nobody ever modifies a model instance expect through its form, right?” which are basically restating the reasons why that feature exists in the first place. > I should have been explicit that I was referring to not being able to define such computed columns on the model the way one would a normal column, not to being unable to use `F`-expressions. Strong agreement here. Your post could have been so much more useful if each of the mocking asides had instead been taken as a cue to ask whether it's more likely that so many people have worked on Django for years without noticing such a major flaw or that your understanding of how it was intended to be used is incorrect. Imagine if your post had been something like “Things I learned about Django the hard way” and had covered things like picking safer defaults or updating the docs to more explicitly suggest how validation is intended to work (especially in this age where people use fewer forms and more APIs than a decade ago), or that Django treats the database as the ultimate source of truth so you should approach various things about validation and transactions with that in mind (e.g. strengthening the the wording to make it clear that e.g. get_or_create relies on database integrity checks so you should either set those or religiously use some other strategy). That post could be a DjangoCon talk and it'd get a lot more positive reaction than another angry rant on an internet full of them, especially since people in the community would be likely to share it rather than seeing a big claim which is not correct and closing the tab.
  - alexbecker 8y ago