On Tue, 3 Jun 2008 12:33:25 +0200 ekellner <[EMAIL PROTECTED]> wrote:
> > As I was looking at model inheritance with admin recently, I came > across this issue: > http://code.djangoproject.com/ticket/6755 > > I'm thinking now that the underlying issue that I'm seeing, and what > the patch in 6755 is fixing, doesn't actually have anything to do with > newforms at all. I think it has to do with consistancy of primary > keys in derived models. I don't know if this is a bug, or my own > misuse, but I have a feeling something isn't right here. > > Using the Place,Restaurant example (class Place(models.model), and > class Restaurant(Place)), let's consider what exactly a primary key of > a restaurant is. > > At the database, both the restaurant and place tables have a primary > key. By default, the names are place.id and restaurant.place_id_ptr > (I think -- but they aren't the same). And so, in memory, a > Restaurant object r has a property "pk" which is mapped to > r.place_id_ptr. Similarly, a place object's property "pk" is mapped > to p.id. > > So what exactly does r.pk = 1 do? It sets r.place_id_ptr. Is this > wrong? Shouldn't it also set r.id? To me, this is one object, with > the same primary key across 2 tables. If it were 2 keys, then one > would be a foreign key. But it's not, so it's conceptually one key. > > Alternatively, this is my own bug if it should be the responsibility > of the user to manage both keys independently. > > > In any case, this fix is what the patch for 6755 kind of does. In the > save_base model method, it sets the parent's primary key (r.id) from > the child's (r.place_id_ptr) before saving the parent. I don't think > in any case this is the right design. If the parent's primary set is > to be set from the child's it should be set *on assignment* to r.pk, > or r.place_ptr_id, or both, and not *on saving* to the database. > > It is more intuitive to me that an assignment to r.pk should set the > primary key in the Restaurant class, as well as the primary key in all > parent classes, as the "pk" property is not a database column -- it > refers to a value of the object that is stored in 2 locations. What > does the list think? > > Elizabeth I agree with you, and think this should be better expressed. Perhaps without words which refers to abstract C++ concepts like pointers, and using a vocabulary more adapted to Python. At least this would be more helpful for understanding whats going on there. Regards, Etienne --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
