My fix was to simply set the parent's primary key attribute inside of th child's data, which worked for all cases with the exception of when the parent's primary key had the same name as the child's primary key. Upon the loading of a model like that, i get the error "column name is not unique."
I don't see why a parent model cannot have the same field name as a child model. Is this a seperate bug? Maybe my approach towards solving the problem is incorrect? Do I have a misunderstanding of OneToOneFields? E.g. they shouldn't share pk field names (this makes sense to me)? On Mon, May 19, 2008 at 2:52 PM, Ziling Zhao <[EMAIL PROTECTED]> wrote: > Well, the main problem with the parent table being saved independently of > the children tables is that you could have a fixture that only had the > children, seperate from the parents. So if you load that fixture, they would > have no parents to associate to. > > I submitted a patch to my bug that seems to fix it in the deserialization > part by setting the parents pk before converting it to an object. This > should hopefully make it save/update correctly. > > > On Sat, May 17, 2008 at 12:41 PM, AmanKow <[EMAIL PROTECTED]> wrote: > >> >> On May 15, 6:15 pm, "Ziling Zhao" <[EMAIL PROTECTED]> wrote: >> > So, are you suggesting that on fixture loading that parents should *not* >> be >> > saved? >> > >> > Would this possibly allow you to load fixtures that don't fit in your >> model? >> > E.g. children without parents? >> >> No, what I'm suggesting is that the parent table is being saved, >> independently of the child tables. Later, the children are saved. I >> am suggesting that on load, after the parent tables are loaded, the >> children be loaded and only the child tables be touched. >> >> BTW, in your item below, parent_ptr is the primary key of the child, >> foreign keyed to the parent, implicitly created by using multitable >> inheritance. Thus MTI is just a special case of one to one where the >> one to one field is also the pk. >> >> On May 15, 6:15 pm, "Ziling Zhao" <[EMAIL PROTECTED]> wrote: >> > So, are you suggesting that on fixture loading that parents should *not* >> be >> > saved? >> > >> > Would this possibly allow you to load fixtures that don't fit in your >> model? >> > E.g. children without parents? >> > >> > >> > >> > On Sat, May 10, 2008 at 10:24 AM, AmanKow <[EMAIL PROTECTED]> wrote: >> > >> > > Above, I said: >> > > > I notice that child instances have an undocumented save_base method, >> > > > which I assume is called from the child's save. I wonder if it >> might >> > > > not be useful to have some way (r.save(exclude_parent=True) or some >> > > > such thing) in order to save the child record only. >> > >> > > But I didn't explain why I thought something like this might be useful >> > > for some types of processing and applicable to the loaddata issue. >> > >> > > For hooking up children to existing parents it would be simpler and >> > > more efficient: >> > > >>> p = Place(name="Lee's Tavern", address="Staten Island") >> > > >>> p.save() >> > > >>> r = Restaurant(serves_pizza=True, serves_hot_dogs=False, pk=p.pk) >> > > >>> r.save(child_only=True) >> > >> > > You'd have to be a bit cautious here, as r will still have the default >> > > values for the parent fields. If you are going to continue to use r, >> > > and access the parent fields in any way, the following would be >> > > appropriate after the save: >> > > >>> r = Restaurant.objects.get(pk=r.pk) >> > >> > > If indeed there is some sort of transactional issue in loaddata, >> > > always specifying that only the child be saved (it wouldn't hurt to >> > > specify it everywhere loaddata saves as it would be ignored where it >> > > wasn't pertinent) might just be the fix. >> > >> > > Wayne >> > >> > -- >> > ~Ziling Zhao >> >> >> > > > -- > ~Ziling Zhao > -- ~Ziling Zhao --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
