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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
