Hi Lior, (moved from another thread) On Apr 29, 12:16 am, Lior Sion <lior.s...@gmail.com> wrote: > I looked at the sample you wrote on the other thread (unique together > on username and date, and having a null username with a given date) of > when the old behavior is the right one and it didn't quite convince me > - I do believe that the right implementation would fail a case of > NULLed username and repeating dates, when a unique together exists.
That would clearly violate the currently-established consistent semantic for modelform validation, which is that the modelform only validates the fields that are actually included in the form. Any fields that are not included in the form, it must be assumed that they might change before saving, and their current value is unreliable (it might just be the default value for a new object, or something else entirely, it's not necessarily a value that's actually intended to be validated or saved). In essence, what you are proposing is validation of "possibly-junk" data. Because of this, any fix has to be absolutely 100% sure that it will never generate a false positive on the unique_together check because of the non-included field's value, or else we're violating the documented expectation that non-included fields' values are not part of validation. The exceptions for default and blank in the current patch was my best attempt to achieve that, but I don't even think that's sufficient - really, modelform validation can't assume anything about the data on self.instance for fields that aren't in the form, regardless of whether the field is blank or has a default. This is why I'm saying that the current expected semantics, that a modelform can provide meaningful validation while ignoring some fields of the model, is inherently broken. No matter what you do with constraints that include some included and some excluded fields (whether they are unique_together or custom clean methods, as in Mikhail's example), you're doing the wrong thing - you can't validate the constraint because you can't use some of the data that's needed to validate it, but if you drop the constraint entirely (as we do now) you require the developer to re-validate everything themselves later (and probably stuff those later model-validation errors back into the form, too, and then break out of the is_valid clause because its no longer valid), which is really ugly and painful in custom code and currently not done at all in the admin. And that's why I think the only long-term solution, that isn't just going to cause more problems, is to begin moving towards a new expectation for validating modelforms, where its expected that full model validation is run, and any tweaks to the model must be made before validation rather than after. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
