About two months ago, ticket #25548[1] was opened, pointing out that on an invalid form submission, FormView was calling form validation methods twice (what was actually happening was that the original form instance was discarded, a new one constructed with the same data, and the first access to its errors or cleaned_data would run validation on the new instance).
As noted on the ticket, that was fixed in master in e171a83[2], and the ticket was closed about one month ago. However, the fix was not backported into the (at-the-time unreleased) 1.9.x branch, and so this bug is present in Django 1.9, as I discovered while investigating a bug report submitted to django-registration. I asked around on IRC and nobody present seemed to know why it wasn't backported at the time of the commit. Obviously the bug was not treated as a release blocker for 1.9, and does not cause a security issue, crash or data loss, which means an argument can be made that our policies don't support backporting this fix to 1.9. Acknowledging that, I'd still like to argue for it to be backported to 1.9, for three primary reasons: 1. This is a performance regression, and potentially a significant performance regression. Form validation can be quite complex, and very often involves performing database queries; depending on the form, it may also involve accessing other services over a network. If Django 1.9 effectively causes that work to be doubled on invalid submissions, that's a strong argument against using Django 1.9. We shouldn't be in the business of incentivizing people not to use the latest release. 2. While an argument can be made that it doesn't *technically* violate any documented guarantees, the way in which Django's form system is implemented and designed carries with it a strong implication that validation methods are only called once per form submission. Many developers work under that implication, and rely on it when designing their form validation schemes. We should not break that without heavily warning and documenting it, which we haven't done. 3. Fear of the unknown. The history of the Web is littered with cases where, despite the fact that best practices involved writing idempotent code, large numbers of people didn't write idempotent code and bad things happened the instant it was accessed in ways which assumed idempotence (for example: URL prefetching features accidentally triggering data loss or data modification due to Web services not being idempotent on GET). While I can't off the top of my head come up with any realistic example where a non-idempotent form validation method would cause a crash, security issue or data loss, experience has shown that I am not imaginative enough to figure out what people will do in the real world. We should not be inviting those kinds of hard-to-imagine problems by not backporting this fix. So I'd like to propose that e171a83 be backported into the 1.9.x branch, to be included in the first bugfix release of the 1.9 series. Thoughts? [1] https://code.djangoproject.com/ticket/25548 [2] https://github.com/django/django/commit/e171a83b1516a3a2a393a5300527af1aab21c213 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-8eovA-CwfgyYUf_Hg5%3DESy_x-RE2yJBOLMZ_Mz1dHdA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
