Clarification on Foreign Keys requested

21 views
Skip to first unread message

Malik Rumi

unread,
Mar 5, 2018, 5:06:22 PM3/5/18
to Django users
Hello all,

Up to now, (admittedly not long - I'm not a total newbie but I still have a LOT to learn) when making a foreign key I would just put the pk of that instance in the fk field, as the docs suggest:

By default ForeignKey will target the pk of the remote model but this behavior can be changed by using the ``to_field`` argument.


However, recently while working with a scrapy pipeline, these fields started catching errors, which told me

"...must be an instance of ...(foreign object)"

And sure enough, if I did a get queryset for the one specific instance in question, that worked. My question is why, or maybe it should be, what's the difference, or maybe even, what's going on here, or wtf?

Any light you can shed on this for me would, as always, be greatly appreciated.

Bill Freeman

unread,
Mar 5, 2018, 5:17:04 PM3/5/18
to django-users
Are you specifying the to_field argument, or are you letting it default?

And is the pk of the other model made by Django by default, or are you explicitly specifying a foreign key constraint on some field of your own.

Things might be better in 2.0, but I've had my troubles with pk that isn't an AutoField (such as made by default).

If you're only doing the standard (defaulted) stuff, it's a mystery.  Either way folks probably need to see some of your code to help out.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5f9399d4-6a48-450a-b2bd-2e33a296b1b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Malik Rumi

unread,
Mar 5, 2018, 6:23:55 PM3/5/18
to django...@googlegroups.com
I tried the to_field argument, that was a mistake, and I put it back.

I was just inserting the pk of the foreign object. However, as things are moving through the pipeline, I used uuid.uuid4() to create additional pks as needed at it went along.

Example:

    def process_item(self, item, spiders):
        itemcasebycase['case_arrow'] = item['uniqid']
        itemcasebycase['uniqid'] = get_u

But this is what works in the pipeline:

        scotus = Jurisdiction.objects.get(
            uniqid='5e4dd0c2-5cc9-4d08-ab43-fcf0e84dfc44')
        item['jurisdiction'] = scotus

And this is the error message I got:

ValueError: Cannot assign "UUID('5e4dd0c2-5cc9-4d08-ab43-fcf0e84dfc44')": "Case.jurisdiction" must be a "Jurisdiction" instance

Finally, yes, under normal circumstances, my pk uuids are made automatically. Thanks

“None of you has faith until he loves for his brother or his neighbor what he loves for himself.”

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/GDuwEZXyQ3k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

Bill Freeman

unread,
Mar 6, 2018, 9:58:47 AM3/6/18
to django-users
When all is as usual, you don't play with pk in your code.  You put the foreign object in the field of the referring object.  (In python that's just a reference, so don't worry about copies, etc.)  When the referring object is saved, django saves the pk of the object in the field in the db in a field called foo_id, if the field itself is called foo. Later when  you fetch the referrer, say as bar, then when you refer to bar,foo django makes sure the foo object has been fetched, so bar.foo.ugh get's you the ugh field of the foo object referred to by bar.

I suggest that with this in mind, you go back of the part of the tutorial example that talks about foreign keys and see how many of the things that you're doing aren't required, and are just opportunities to confuse things.

Reply all
Reply to author
Forward
0 new messages