Hi Carl- > Hmm, that's interesting. I'm not super-enthused about the complexity > there (Zen of Python: "if the implementation is hard to explain, it's a > bad idea"), but I think you're right that it's feasible. Note that > nullable fields would be ok to go ahead with (because NULL is not equal > to NULL in SQL, it won't cause false positives on the uniqueness check); > it's just fields with non-null defaults that could cause the false > positive if they are excluded from the form but included in a > unique-together check. > > If the implementation (and documentation) for that patch doesn't look > too terrible, I'd consider it - I do think it gets the behavior closer > to right than what we do now, and I'm not sure it's really possible to > get it fully right in all cases as long as we're trying to do validation > on a partial model. I'd be interested in others' thoughts, of course.
Ok, I'll create a patch soon (with tests + documentation) that hopefully works for you. I don't think it will be very complicated implementation-wise, just a few additional lines, I think. With regards to the documentation, I'll add a note here: http://docs.djangoproject.com/en/1.3/ref/models/options/#unique-together and here: http://docs.djangoproject.com/en/1.3/ref/models/instances/#django.db.models.Model.validate_unique Including a note saying that the behavior has changed Regards, Eduardo -- 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.
