I've been hooking up child instances with existing parent instances
without problem, which seems entirely similar:
class Place(models.Model):
name = models.CharField(max_length=50)
address = models.CharField(max_length=80)
class Restaurant(Place):
serves_hot_dogs = models.BooleanField()
serves_pizza = models.BooleanField()
class Bar(Place):
has_happy_hour = models.BooleanField()
checks_id = models.BooleanField()
>>> p = Place(name="Lee's Tavern", address="Staten Island")
>>> p.save()
>>> p_dict = Place.objects.filter(pk=p.pk).values()[0]
>>> r = Restaurant(serves_pizza=True, serves_hot_dogs=False, **p_dict())
>>> r.save()
Is the child save in deserialization essentially any different from
this? It is a bit less than maximally efficient, as the parent is
created and then updated unnecessarily with the same information
through the child, but it does work. Could this be some sort of
transaction issue?
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.
Wayne
On May 9, 6:25 pm, "Ziling Zhao" <[EMAIL PROTECTED]> wrote:
> The problem is that the parent object is saved, and then child object is
> saved. When the child model is saved it attempts to create the parent object
> again. It then fails constraints.
>
> After playing around with it a bit, it makes sense that the fix shouldn't be
> in the model.save().
>
> However, it would mean that in the deserialization process, any parent
> models would have to be 'held back' from being saved until the children are
> saved. Afterwards, parent models would need to be compared to the parent
> models created by the children to see if there are any redundant models,
> which would then be discarded.
>
> This sounds kind of kludgy though.
>
> The alternative fix that I was thinking about was to change model.save() to
> do something special for onetoone's where it would,instead of creating a
> parent, associate itself to an existing parent that matches what it's actual
> parent would be. Upon finding a parent that already has a child, it would
> die.
>
> This one also sounds a bit forced to. And it sounds like there's a whole
> list of complications that would come attached to that which would make it
> one hairy thing to deal with.
>
> Any other ideas? I'm currently unaware of any elegant solutions.
>
> On Thu, May 8, 2008 at 9:53 PM, Russell Keith-Magee <[EMAIL PROTECTED]>
> wrote:
>
>
>
>
>
> > On Fri, May 9, 2008 at 7:17 AM, Ziling Zhao <[EMAIL PROTECTED]> wrote:
> > > I filled a bug here about multi-table inheritance problems and fixtures:
> > > http://code.djangoproject.com/ticket/7202
>
> > > In the case that it is valid, I decided to look through the core code to
> > see
> > > where a fix could be placed.
> > > I've looked through it for a bit and it seems like it makes the most
> > sense
> > > in .save() but I'm unsure of that.
>
> > > Does fixing it in model.save() makes the most sense?
>
> > It depends on exactly what the problem is. I haven't looked into the
> > problem in detail, but I'd be surprised if the solution lies in
> > model.save().
>
> > You have encountered this problem as part of the deserialization
> > process. The only way that the solution will lie in model.save() is if
> > you have found a problem with model saving itself - i.e., the problem
> > isn't with deserialization, but with the way models are saved. The
> > test for this - is it possible to generate this error _without_ using
> > loaddata? Can you stimulate the same error with normal
> > "object.property = foo; object.save()" calls?
>
> > If the answer is yes, then the solution may lie in model.save().
> > Otherwise, you'll be looking in the deserializer (or serializer) for
> > the solution.
>
> > Yours,
> > Russ Magee %-)
>
> --
> ~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
-~----------~----~----~----~------~----~------~--~---
