In addition, it seems like my patch works for sqlite and mysql, but will fail under postgres.
On Tue, May 20, 2008 at 3:09 PM, Ziling Zhao <[EMAIL PROTECTED]> wrote: > 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 > -- ~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 -~----------~----~----~----~------~----~------~--~---
