I know this is a VERY VERY old thread but oh my god I love you, I was
having the same problem for the same reason and would have never imaged
that was why (though it makes sense). Took me a long time to finally find
this thread.
On Thursday, January 22, 2009 1:38:57 AM UTC-2, Keyton Weissinger wrote:
>
> OK. I figured it out and it was VERY STRANGE. Maybe some one reading
> this can tell me WWWHHHYYY my solution works. For now, it's voodoo to
> me...
>
> Turns out that some of my code (in the view where I was having
> trouble) called some code that looked sort of like this:
>
> field_list = model._meta.fields
> field_list.extend(model._meta.many_to_many)
> for field in field_list:
> related_model_name = None
> related_model_app_name = None
> if (not field.name[-4:] == '_ptr') and (not field.__class__ ==
> AutoField):
>
> if issubclass(field.__class__, related.RelatedField):
> if not field.__class__ == related.ForeignKey:
> related_model_app_name = field.rel.to.__module__.split
> ('.')[0]
> # We'll ignore all django-specific models (such as
> User, etc).
> if not related_model_app_name == 'django':
> related_model_name = field.rel.to.__name__
> full_related_model_name = '.'.join
> ([field.rel.to.__module__, related_model_name])
> relation_tuple_list.append((full_model_name
> +'%relation'+field.name+'%' + full_related_model_name, \
> 'Mapping: ' +
> model.__name__ + '-' + \
> related_model_name))
> else:
> continue
>
> It is just pulling together a list of relationships between two
> models. I'm not using these models to actually DO anything. Just what
> you see.
>
> I could go to the command line and do the following:
> >>> from batchimport.forms import ImportOptionsForm
> >>> from sbase.models import Student
> >>> mydict = {'city': u'Columbus', 'first_name': u'Jimmy', 'last_name':
> u'Jones', 'zip': 43215.0, 'title': u'Mr.', 'dob': '1956-12-29',
> 'phone_primary': u'614-468-5940', 'state': u'OH', 'address': u'142, Quilly
> Lane', 'type': u'Student', 'email': u'miles...@spambob.com <javascript:>'}
>
> >>> mystudent = Student(**mydict)
>
> The import of ImportOptionsForms, it turns out, called the above code.
>
> OK. The above series of commands would fail every time with the
> following error.
> 'Student' instance needs to have a primary key value before a many-to-
> many relationship can be used.
>
> I was close. I could repeat my strange in-app problem on the command
> line. Yea.
>
> So after a LONG time of messing with it, it turns out that django
> didn't like how I was handling the many-to-many fields
> (model._meta.many_to_many).
>
> But I was able to fix my problem by just doing this:
>
> for field_list in [model._meta.fields, model._meta.many_to_many]:
> for field in field_list:
> related_model_name = None
> related_model_app_name = None
> if (not field.name[-4:] == '_ptr') and (not
> field.__class__ == AutoField):
>
> if issubclass(field.__class__, related.RelatedField):
> if not field.__class__ == related.ForeignKey:
> related_model_app_name =
> field.rel.to.__module__.split('.')[0]
> # We'll ignore all django-specific models
> (such as User, etc).
> if not related_model_app_name == 'django':
> related_model_name = field.rel.to.__name__
> full_related_model_name = '.'.join
> ([field.rel.to.__module__, related_model_name])
> relation_tuple_list.append((full_model_name
> +'%relation'+field.name+'%' + full_related_model_name, \
> 'Mapping: ' +
> model.__name__ + '-' + \
>
> related_model_name))
> else:
> continue
>
> YEAH! That's all I changed. Instead of extending my list of fields
> with the many_to_many fields, I just iterated over one (to get the
> ForeignKey relationships etc, and then I subsequently iterated over my
> many-to-many fields.
>
> Why (the HELL) does the first version trigger this error:
> 'Student' instance needs to have a primary key value before a many-to-
> many relationship can be used.
>
> But the second version doesn't?
>
> If I'm an idiot, PLEASE tell me how so, because I'd really like to
> avoid this kind of quagmire if I can....
>
> Thank you VERY MUCH Martin and Malcolm. I appreciate your respective
> looks at this problem very much. Your taking time to help with this
> kind of thorny issue is what makes this community rock and, frankly,
> inspires me to help out more.
>
> Keyton
>
> On Jan 21, 3:59 pm, Keyton Weissinger <key...@gmail.com> wrote:
> > Hmm. Thanks Martin. I will try with the SVN HEAD revision. I have
> > already tried the Student(**mydict) approach and get the exact same
> > issue. I will test tonight and respond. Thanks very much for taking
> > time...
> >
> > Keyton
> >
> > On Jan 21, 3:24 pm, Martin Conte Mac Donell <refl...@gmail.com> wrote:
> >
> > > Again, i can't reproduce your problem.
> >
> > > It's working using SVN HEAD with your model and this view:
> http://dpaste.com/111590/. Could you try to use that dict and
> > > Student(**mydict) instead of
> > > "model_import_info.model_for_import.objects.create" ?
> >
> > > Regards,
> > > M
> >
> > > On Wed, Jan 21, 2009 at 3:06 PM, Keyton Weissinger <key...@gmail.com>
> wrote:
> >
> > > > I'm on django 1.0.1 (NOT 1.0.2). Do you think that has any impact on
> > > > this problem? I will try upgrading tonight.
> >
> > > > Any other ideas?
> >
> > > > K
> >
> >
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/66f72644-dde6-4009-b020-5848a1c4e585%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
