#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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
