FWIW I was very surprised when I realized this problem. I couldn't understand
why a model object with an email field (without `blank=True`) could be saved
with an empty string as email address.
The way I dealt with this was creating a mixin (ValidateModelMixin) and adding
it as left-most
Sounds good. I guess that may be an addition here:
https://docs.djangoproject.com/en/dev/ref/models/instances/#validating-objects
On Tuesday, October 22, 2013 8:40:46 AM UTC-4, Cal Leeming [Simplicity
Media Ltd] wrote:
>
> It seems there is a split reaction on whether or not models should
It seems there is a split reaction on whether or not models should assume
data is clean, and comes down to design decision.
I think that a docs patch explaining this entire concept to new users would
be sufficient for now (and I'm more than happy to spend time writing it).
Would any of the core
Sorry please ignore my last email, my email client went a bit weird and
sent the draft whilst I was still editing/thinking. Here is the proper
version;
This is yet another reason why I don't think it would be reasonable to
expect field validation within the model.
If the validations were done
On Friday, October 18, 2013 12:03:42 AM UTC+2, lucmult wrote:
>
> I think it's reasonable to assume that by default we want our data to be
> consistent.
>
I disagree, everything which isn't coming from user input should not need
validation, since you really __should__ know what you are putting
On Friday, October 18, 2013 4:28:21 AM UTC+2, Karen Tracey wrote:
>
> Wasn't there also concern for double validation performed during form
> clean and then model instance save?
>
Yes, technically we would probably have to track the validation state per
field and also track changes to it etc…
On Friday, October 18, 2013 5:28:21 AM UTC+3, Karen Tracey wrote:
>
>
> On Wed, Oct 16, 2013 at 7:03 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>>> 1) Without taking backwards compatibility into consideration, is it
>>> reasonable to expect field validation automatically
On Wed, Oct 16, 2013 at 7:03 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
>> 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
A few cents...
First, a project wide settings to control this behaviour would be complex
with pluggable apps. Some apps might expect global valodation enabled, but
some might expect it disabled.
We should have model.save validating by default and have a flag to turn it
off. I think it's
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
On Wed, Oct 16, 2013 at 12:15 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> 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
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
I'd considered having a `validate` attribute on save(), but this feels
unnecessary because we can already have model.full_clean(), having
`validate` seems superfluous.
One idea I'd had was to only validate fields which had changed. The reason
for this is because we cannot assume data in the model
One problem with it as you've found is that you sometimes do want control
over it on a per-model or even per-instance (per-save) basis. One way to
deal with this is to create something like the following that you can
extend in your models:
class ValidatedModel(models.Model):
def save(self,
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
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
16 matches
Mail list logo
