On Thu, Mar 26, 2009 at 7:06 AM, TeenSpirit83
<[email protected]>wrote:
>
> I can't find nothing similar on this group! Can you please help me?
> I get this error trace in the django 1.0.2 admin when updating a char
> primary key in a regex field.
> Thank you in advance!
>
I think there's a bit more going on here than you actually describe. Based
on the traceback, you are dealing with an admin page that contains an inline
formset, and you don't mention that at all. I've recreated what you are
describing with a couple of simplified models and admin defs:
# models.py
from django.db import models
class ExplicitPK(models.Model):
expk = models.CharField(max_length=24, primary_key=True)
def __unicode__(self):
return self.expk
class AssociatedThing(models.Model):
name = models.CharField(max_length=8)
expk = models.ForeignKey(ExplicitPK)
def __unicode__(self):
return u'%s associated with %s' % (self.name, self.expk)
# admin.py
from django.contrib import admin
from expk.models import ExplicitPK, AssociatedThing
class AssocInline(admin.TabularInline):
model = AssociatedThing
class ExplicitPKAdmin(admin.ModelAdmin):
inlines = [AssocInline]
admin.site.register(ExplicitPK, ExplicitPKAdmin)
If I now go into admin and create an ExplicitPK object with the primary key
'First', and a couple of AssociatedThing objects inline, all is well. If,
however, I then try to change the 'expk' field value from 'First' to
'Second', and select 'Save', I get a traceback similar to what you report
(slightly different because I'm running with trunk code, not 1.0.2).
The reason, I think, has to do with the fact that the POST data for the
admin page with inlines contains information for the (in the case I tested
2) related objects that point to 'First', but after I change the primary key
value to 'Second', a queryset of AssociatedThing objects that point to
'Second' returns 0 results. The admin tries to create a formset using a
queryset that specifies the new pk value, but the objects in that queryset
don't match up to the POST data in the request. This mismatch results in the
the formset creation code causing list index out of range when trying to
match up the POST data with a non-existent matching objects in the queryset
of AssociatedThings related to 'Second'.
Now, the admin (or maybe it's basic formset) creation code might should
handle this more gracefully, when the POST data doesn't match the actual
queryset (and there's at least one ticket open on that issue, since it also
surfaces when ordering differs from call to call), but I'm not sure even if
it did that you'd be getting the results you are expecting. What do you
expect to happen when you change the primary key of an object?
What does happen is that an entirely new object is created. The primary key
value of the existing database row is not changed. That's just how the ORM
works, I believe. When you change the primary key value in the in-memory
model object, the ORM has no way, so far as I know, to know that the primary
key value used to be something else. So when the object is saved, you just
wind up creating a new object (assuming you pick a primary key value that
doesn't already exist in the table), because the ORM has no way of knowing
that this in-memory model object used to refer to a database row that has a
different primary key value.
If this is not what you were expecting, you might want to re-think having
your models declare an explicit primary key, particularly if you are
expecting to allow changing the values.
Karen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
