On Tue, Oct 15, 2013 at 11:43 PM, Cal Leeming [Simplicity Media Ltd] < [email protected]> wrote:
> Hello, > > I am trying to understand why field validators (model.full_clean()) are > not called for model.save() > > I've spent about an hour reviewing all the discussions/replies on this > subject; > http://www.xormedia.com/django-model-validation-on-save/ > > http://stackoverflow.com/questions/4441539/why-doesnt-djangos-model-save-call-full-clean > https://code.djangoproject.com/ticket/13100 > https://groups.google.com/forum/#!topic/django-developers/uIhzSwWHj4c > > From what I can tell this was rejected on the basis of breaking backwards > compatibility. > > It is unclear whether this would have been desired behavior had backwards > compatibility not been an issue. > > It also seems to me that it would be possible to maintain backwards > compatibility by using settings flags to determine the default behavior, > albeit at the cost of increased complexity. > > So I have four questions; > > 1) Without taking backwards compatibility into consideration, is it > reasonable to expect field validation automatically upon calling > model.save() > Yes. Based on the original discussions (as I recall them), this wasn't in question -- the problem was entirely backwards compatibility. > 2) At what point would Django devs be willing to break backwards > compatibility? Would this be considered on 2.x, or is it life time? > Well… ideally never. :-) Pragmatically, we will make backwards compatible changes as long as there's a clear migration path. The version number isn't something to get hung up on; I'm not expecting 2.0 to be a "massive change" release in the same way that Python 3.0 was. If we can get the solution right, we'll just do it, not wait for a particular version number. The approach we've taken to backwards incompatibility issues is to introduce them slowly -- to provide lots of warnings that something is going to change, provide opt-in for those that want to migrate, and ensure that all new projects use the new behaviour. The change to the {% url %} tag, for example, has taken almost 4 years to complete, which has given everyone plenty of time to adapt. 3) Could backwards compatibility not be maintained by means of a flag in > settings? For example, settings.MODEL_VALIDATE_ON_SAVE=True would cause the > validation to be handled using the new approach? > Historically, we're not wild on introducing new settings, especially for behaviour changes. However, we obviously need to have a way to flag 'use the new behaviour'. The only other option I can think of would be a Meta flag on individual models, but that obviously makes it difficult to turn on the feature project-wide. 4) Assuming this cannot/will not be implemented, what would be the most > suitable workaround? Are there any risks in calling full_clean() without > ever using ModelForm? Should ModelForm always be used instead of using a > model directly? etc. > At the simplest level, rewriting Model.save() to invoke Model.full_clean() should be all the workaround you need. As for risks - none that I can think of. Model validation is independent of the forms framework; you can use model validation without ever using ModelForms. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" 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/CAJxq849zb2F9H-WH%2BBrB8PFVxab596m4VRbRExGpVgF98nfd9Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
