I ran into the same problem today in a script for creating large amounts of
test data. It would be awkward to re-organize the code it such a way that
related objects are assigned to fields only after they've been saved, so I
made a utility method to a take a model instance which has fields which
Thanks for the detailed responses, they helped clarify things a lot.
I will try the first option you mentioned about creating the Questions
first (and saving them) and then creating the Choices using the Questions
that were just created.
My back-up plan will be to use a different pk field for Qu
On Monday, November 28, 2016 at 3:12:37 PM UTC+2, Michael Viveros wrote:
>
> Thanks for the reply Kirby.
>
> I understand that the Question's pk is null when you pass in the Question
> to the Choice constructor. But when you save the Choice, the Question was
> saved earlier so the Question's pk
Thanks for the reply Kirby.
I understand that the Question's pk is null when you pass in the Question
to the Choice constructor. But when you save the Choice, the Question was
saved earlier so the Question's pk is not null. But the Choice's
question_id attribute (representing the Question's pk)
The reason it isn't working in your first example is because the pk gets
assigned to the object when it is saved to the database. When you supply
question=q to the choice, it is (correctly) getting a pk of null because q
has not been saved.
On Saturday, November 26, 2016 at 2:56:37 AM UTC+2,
I have a Question model and a Choice model where a Question can have many
Choices so the Choice model has a Foreign Key mapping to a Question.
models.py:
from django.db import models
class Question(models.Model):
text = models.CharField(max_length=200)
title = models.CharField(max_leng
6 matches
Mail list logo
