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.l.ye...@spambob.com'}
>>> 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 post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to