Karen you're always a big help for me on django. Thank you so much! I was imaging the same thing you explained about problems with the objects pointing to the key i want to change. So I was thinking to create a new counter primary key for that model and turn the current primary key into a simple unique attribute. But I posted this thread hoping there could be some error and some solution without the need to change the model. I think this is what I'm gonna do.
On 26 Mar, 20:57, Karen Tracey <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
