Sorry I should have made myself a little more clear.

When I said "invalidating data inside your models" I was referring to any
previous data that was saved when the validator was set to a minimum length
of 4 characters. By then changing the validator to be 5 characters, you are
effectively breaking save() on any data that was saved before that point,
and the ability to fix the model data may not be available in that specific
save() context. For example, a cron job that updates a "last_checked" field
on the user would not necessarily have data relevant to changes in the
users phone number (which could have its min/max length changed at any
point in the validators life time).

Hope that makes more sense

Cal


On Tue, Oct 15, 2013 at 5:12 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> I've been thinking about this a little bit more, and it seems that the
> design approach of validating on save() is not entirely correct.
>
> For example, say you have a validator that ensures a field must be at
> least 4 characters long, and a few months later the validation is then
> changed to be 5 characters long. This means any save() call on that field
> (which may include a modification to a field which is unrelated to the
> change being made) will then stop that save from happening. By applying the
> validation at the model level, you are then potentially invalidating data
> inside your models. This is fine for forms, because it can be handled at
> the user side (by returning a form error saying X field is incorrect), but
> would cause problems at the model layer.
>
> I think by design it would be very wrong to validate the model fields at
> the point of save(), despite seeming like it would be the correct thing to
> do.
>
> Could someone please verify if I have come to the correct conclusion here?
>
> Cal
>
>
> On Tue, Oct 15, 2013 at 4: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()
>> 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?
>> 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?
>> 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.
>>
>> Any comments/feedback would be much appreciated, I am also happy to spend
>> time updating docs to reflect responses in this thread.
>>
>> Thanks
>>
>> Cal
>>
>
>

-- 
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/CAHKQagEXvMe0Te%2B8KtEGTR44pEXDBWkH7rFT%3DVjYogukeY6QKA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to