On Tue, Oct 15, 2013 at 11:43 PM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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.
