Thank you for the detailed reply, much appreciated. I think the problem isn't just storing model validations with migrations, because it's probably good practice for any developer to assume that field data may be invalid (i.e. manual field/table changes, unknown validation bugs from previous releases, buggy migration scripts etc). And a for/model.save() loop would only work if auto-repair was feasible, in which case the developer has to decide how to handle validation failures at certain points in the code. The typical scenarios you'd handle when encountering invalid data would be to ignore, repair or error - depending on where you are within the code.
The approaches that come to mind are; 1) save(validate=True) This still feels superfluous because we can just call full_clean() before save(). 2) full_clean() then save() This works but you have to manually check the errors to see if it was old or new data that causes validation 3) save(validate_only_changes=True) OR full_clean(validate_only_changes=True) Feels a bit better as it allows me to handle background jobs gracefully, say a cron that is failing on a record that it doesn't know/need at that point of execution. 4) CharField(validate_old=True) This would not allow context specific handling (i.e. we want to enforce validate old if we have a user request because we can ask them for updated info, but do not enforce validate when inside a background job which does not have the necessary context to request repair) >From what I can tell, 3 would be a good approach based on the logic of making it easier for the developer to decide how the failed validation should be handled at certain points in the code. Do you think that `save(validate_only_changes=True)` would be a good approach (worthy of a patch), or am I over-engineering this problem? Cal On Thu, Oct 17, 2013 at 12:08 AM, Russell Keith-Magee < [email protected]> wrote: > > On Wed, Oct 16, 2013 at 12:15 AM, Cal Leeming [Simplicity Media Ltd] < > [email protected]> wrote: > >> 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 >> >> Your analysis is correct, but you're possibly over thinking this a bit. > > Consider a world in which model validation *was* on by default. You write > some models with a char field, and you insert some data. All valid, all > saved successfully. Now you change your models and add a validation > condition. You've just exposed yourself to exactly the same situation, > without feature-level backwards compatibility ever being part of the > picture. > > What this highlights is that migration needs to be part of the whole > solution. At the very least, as part of adding default model validation, > we'd need to document the fact that all existing data must be assumed to be > potentially invalid, and provide an easy way to force validation. > Unfortunately, there's not sure I see any easy way to do this other than a > "for model in database: model.save()" loop. > > 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/CAJxq848-%3DwSerY4HT9zAcff9YVtjQLm7Xf6EmA_JhF3MX7xFkA%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/CAHKQagFR811sPZPyvKgqDUndJx-rAVFHWT6O8N4kpZFBKxsXZg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
