You know, I think that did it. For anybody who ever follows in these
footsteps of error and misdeed, here's what I did to sort out my
tables.
ALTER TABLE app_model CHANGE fk1_id fk1_id int(11) NULL;
ALTER TABLE app_model CHANGE fk2_id fk2_id int(11) NULL;
ALTER TABLE app_model CHANGE fk3_id fk3_id int(11) NULL;
UPDATE app_model SET fk1_id = null WHERE fk1_id = 0;
UPDATE app_model SET fk2_id = null WHERE fk2_id = 0;
UPDATE app_model SET fk3_id = null WHERE fk3_id = 0;
I think added "null=True" to all each field in my models.py and ran
dumpdata again. It seemed to hum along fine, but now I'm running into
a new problem. I think dumpdata is aceing my Macbook Pro's memory. The
database I'm trying to dump is about a half million records, so it
just ground around for a while and then spit out.
"""
Python(327) malloc: *** vm_allocate(size=8421376) failed (error
code=3)
Python(327) malloc: *** error: can't allocate region
Python(327) malloc: *** set a breakpoint in szone_error to debug
Out of memory (Needed 8164 bytes)
Error: Unable to serialize database: (0, '')
"""
Oh dear. Any idea how I can kill that?
On Oct 22, 4:30 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 22, 2008 at 6:37 PM, perchance <[EMAIL PROTECTED]> wrote:
>
> > Thanks for the reply. I did not syncdb with any blank=True or
> > null=True options on the foreignkeys, so the MySQL table does not
> > allow null values. I just ran some group and counts from the mysql
> > shell and it does indeed show that a number of records have a zero in
> > their fk_id field. So I'm now leaning toward that being the problem,
> > since it seems to match what the traceback is pointing to as a
> > problem.
>
> > So what's the right cleanup? Alter the column so it allows nulls,
> > update the zeros to nulls and then flip some null=True options into my
> > models.py?
>
> That's probably what I'd try.
>
> Karen
>
>
>
> > On Oct 22, 3:29 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> > > On Wed, Oct 22, 2008 at 6:14 PM, perchance <[EMAIL PROTECTED]>
> > wrote:
>
> > > > [trimmed]
> > > > python manage.py dumpdata app_label --traceback --indent 4 > fixtures/
> > > > app_label.js
>
> > > > And the traceback I get looks like this, with a sanitized model name
> > > > substituted for the real thing.
>
> > > > """
> > > > Traceback (most recent call last):
> > > > [snipped]
> > > > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > > > python2.4/site-packages/django/db/models/query.py", line 308, in get
> > > > raise self.model.DoesNotExist("%s matching query does not exist."
> > > > django.db.models.base.DoesNotExist: Model matching query does not
> > > > exist.
> > > > ""
>
> > > > The models.py is pretty simple. There are three models up top, each of
> > > > which is linked to a root model by a ForeignKey field. That root model
> > > > looks something like...
>
> > > > """
> > > > class Model(models.Model):
> > > > title = models.CharField(max_length=300)
> > > > fk_1 = models.ForeignKey(fk_1)
> > > > fk_2 = models.ForeignKey(fk_2)
> > > > fk_3 = models.ForeignKey(fk_3)
>
> > > > def __unicode__(self):
> > > > return u'%s, %s' % (self.fk_1, self.fk_2)
>
> > > > class Meta:
> > > > ordering = ['fk_1',]
> > > > """
>
> > > > The funny thing is that if I comment out that root model and run
> > > > dumpdata again, everything goes swimmingly. So I'm guessing the
> > > > problem is in there somewhere. As I've typed out this entirely too
> > > > long email, I've started to think and maybe come up with the weird
> > > > thing I did to screw it up. Would it matter if I initally imported
> > > > that data outside of Django into the model and maybe stupidly left
> > > > some of the FK fields null? Well, I think I'm going to go try that
> > > > right now. If it's something else obvious, please let me know.
>
> > > Assuming the fields are defined to Django to allow null, and are actually
> > > null and not, say, 0, then I don't think nulls would cause this problem.
> > > But it does sound like you've got foreign key values in this table that
> > > don't actually have corresponding rows in the referenced tables. I'm
> > > assuming you've been using MyISAM on MySQL -- it does not enforce
> > > referential integrity, so you can get into this situation pretty easily
> > with
> > > adds/upates/deletes done outside of Django's admin.
>
> > > Karen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
