#9758: modelformset_factory forms generate error when using queryset --------------------------------------------+------------------------------- Reporter: [EMAIL PROTECTED] | Owner: nobody Status: new | Milestone: Component: Forms | Version: 1.0 Resolution: | Keywords: Stage: Accepted | Has_patch: 0 Needs_docs: 0 | Needs_tests: 0 Needs_better_patch: 0 | --------------------------------------------+------------------------------- Changes (by kmtracey):
* needs_better_patch: => 0 * stage: Unreviewed => Accepted * needs_tests: => 0 * needs_docs: => 0 Comment: So I answered on the mailing list (http://groups.google.com/group/django- users/browse_thread/thread/ec6b24a405ea5abe/2a7de9ae3d974bb3) that I thought the problem was that the same queryset wasn't being passed in during POST as had been used during GET, resulting in the edited instances not being correctly matched up with the actual db instances. And that is what's happening, but I'm not sure if the error is in the app code or Django. Can someone who is more familiar with !ModelForm[sets] give some input on whether it is required to pass instance/queryset data in when creating the form during POST processing? What's happening in the case of no queryset being passed in for the formset during POST is that the individual forms (which have hidden ID fields) are being given 'instance' attributes that do not match the instances used to initially create the forms during GET. I've not looked at how this happens, I'm just going by what I see happening in django.forms.models.validate_unique. Say I have a formset with one !StatusReport for pk=3 being posted. When no queryset is passed in to the formset creation during POST, in validate_unique we wind up attempting to check for the uniqueness of the hidden id (pk) field. We exclude from the lookup the object with pk of self.instance, but (in the case I traced through) self.instance had pk=1 (1st in the default unfiltered queryset used when no queryset is specified during formset creation?). So validate_unique finds there's already an object in the db with pk=3, and adds an error for that field which winds up printing out as "(Hidden field id) Status report with this None already exists." The "None" is the non- existent label for the hidden id field. A way to "fix" it (the one I mentioned on the mailing list) is to pass in the same queryset during POST as was used during GET, but that strikes me as somewhat fragile since how can the view code guarantee no changes have been made to the DB in the time between GET and POST that will affect correctly matching up DB instances with the submitted form data? Perhaps an entirely unrelated form has been submitted in the interim that adds a new object that will result in the filtered queryset during POST having more entries than it had during GET, say. The submitted data includes the pk's (though I don't know if this is a requirement or just how it happens by default?). Shouldn't the submitted pk's be what is used during validate_unique when attempting to exclude "this object" from the lookup for uniqueness checking? Even if it's required that the same instance/queryset be passed in during GET and POST I think the doc needs clarification of that, and validate_unique (or some other code) should be changed to generate a more coherent error than what's happening now. Having validate_unique run with self.instance pointing to an entirely different object than is contained in the POST data seems like an error that should be either raised explicitly or caught earlier. Feedback from someone with more a clue in this area would be helpful... BTW this error has been reported at least one other time on the mailing list: http://groups.google.com/group/django- users/browse_thread/thread/37c0672759298e57/b3e109015f4e63d3 without any real resolution. -- Ticket URL: <http://code.djangoproject.com/ticket/9758#comment:1> Django <http://code.djangoproject.com/> The Web framework for perfectionists with deadlines. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django updates" group. To post to this group, send email to django-updates@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-updates?hl=en -~----------~----~----~----~------~----~------~--~---