django model choices is not populating the database
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I have the following code:
class ReportType(models.Model):
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="Earnings"
)
def __str__(self):
return self.report_type
This is just one of the model classes which includes a choices attribute for one of the fields. However, when doing "makemigrations" and then "migrate" the management tool creates the database table but does not populate the database table attribute with the data in the choices which it should do. The result is that when I'm using this model in a modelfrom I get an empty drop-down list when clicking on the dropdown box in the form.
This problems occurs on almost everyone of the model classes which includes the choices field, but one of the model classes is actually working, but it has the same code except from different content in the actual choices.
Does someone know why the django management tool is not populating the data in the choices attribute into the database table ? I cant see any problems with the code.
EDIT:
Modelform for the Report class:
class ReportForm(ModelForm):
class Meta:
model = Report
fields = ['profile', 'name', 'report_type', 'time_period', 'link']
The ReportType does not have a modelform attached to itself, but it is a foreignkey in the Report class.
The Report model has this code:
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.ForeignKey(ReportType)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
The ReportTimePeriod also has a list of choices in one of the attributes so I would expect it to populate the database there as well.
python django django-models django-forms
add a comment |
I have the following code:
class ReportType(models.Model):
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="Earnings"
)
def __str__(self):
return self.report_type
This is just one of the model classes which includes a choices attribute for one of the fields. However, when doing "makemigrations" and then "migrate" the management tool creates the database table but does not populate the database table attribute with the data in the choices which it should do. The result is that when I'm using this model in a modelfrom I get an empty drop-down list when clicking on the dropdown box in the form.
This problems occurs on almost everyone of the model classes which includes the choices field, but one of the model classes is actually working, but it has the same code except from different content in the actual choices.
Does someone know why the django management tool is not populating the data in the choices attribute into the database table ? I cant see any problems with the code.
EDIT:
Modelform for the Report class:
class ReportForm(ModelForm):
class Meta:
model = Report
fields = ['profile', 'name', 'report_type', 'time_period', 'link']
The ReportType does not have a modelform attached to itself, but it is a foreignkey in the Report class.
The Report model has this code:
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.ForeignKey(ReportType)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
The ReportTimePeriod also has a list of choices in one of the attributes so I would expect it to populate the database there as well.
python django django-models django-forms
2
This has nothing to do with the database tables. In fact for most database engines, it never stores the choices at the database level. The choices are typically only verified, etc. at Django level.
– Willem Van Onsem
Nov 26 '18 at 20:29
Can you share a sampleModelFormyou use?
– Willem Van Onsem
Nov 26 '18 at 20:30
Hmm ok. When looking at the model where the choices are being populated in the database.. in the modelform code it refer to it directly while the ReportType does not have a modelform..it is just being linked from Report with a foreignkey. So i suppose you need to have a direct relationship here and that it doesnt work with tables that are just foreignkeys. Then you would need to write scripts that actually populate the database with the necessary values instead of just using the choices attribute for CharField.
– exceed
Nov 26 '18 at 20:45
it indeed stores the choices you make for records, but the column definition does not store the possible choices, these are typically not enforced at database level. If you use aModelFormthen normally it should work. If it works with a "vanilla"Form, you should add aChoiceField, etc.
– Willem Van Onsem
Nov 26 '18 at 20:46
I do not really understand why you here use aReportTypemodel with a choices. Typically you either add such field at theReportclass itself, or you allowReportTypeto have "free" text.
– Willem Van Onsem
Nov 26 '18 at 20:52
add a comment |
I have the following code:
class ReportType(models.Model):
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="Earnings"
)
def __str__(self):
return self.report_type
This is just one of the model classes which includes a choices attribute for one of the fields. However, when doing "makemigrations" and then "migrate" the management tool creates the database table but does not populate the database table attribute with the data in the choices which it should do. The result is that when I'm using this model in a modelfrom I get an empty drop-down list when clicking on the dropdown box in the form.
This problems occurs on almost everyone of the model classes which includes the choices field, but one of the model classes is actually working, but it has the same code except from different content in the actual choices.
Does someone know why the django management tool is not populating the data in the choices attribute into the database table ? I cant see any problems with the code.
EDIT:
Modelform for the Report class:
class ReportForm(ModelForm):
class Meta:
model = Report
fields = ['profile', 'name', 'report_type', 'time_period', 'link']
The ReportType does not have a modelform attached to itself, but it is a foreignkey in the Report class.
The Report model has this code:
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.ForeignKey(ReportType)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
The ReportTimePeriod also has a list of choices in one of the attributes so I would expect it to populate the database there as well.
python django django-models django-forms
I have the following code:
class ReportType(models.Model):
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="Earnings"
)
def __str__(self):
return self.report_type
This is just one of the model classes which includes a choices attribute for one of the fields. However, when doing "makemigrations" and then "migrate" the management tool creates the database table but does not populate the database table attribute with the data in the choices which it should do. The result is that when I'm using this model in a modelfrom I get an empty drop-down list when clicking on the dropdown box in the form.
This problems occurs on almost everyone of the model classes which includes the choices field, but one of the model classes is actually working, but it has the same code except from different content in the actual choices.
Does someone know why the django management tool is not populating the data in the choices attribute into the database table ? I cant see any problems with the code.
EDIT:
Modelform for the Report class:
class ReportForm(ModelForm):
class Meta:
model = Report
fields = ['profile', 'name', 'report_type', 'time_period', 'link']
The ReportType does not have a modelform attached to itself, but it is a foreignkey in the Report class.
The Report model has this code:
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.ForeignKey(ReportType)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
The ReportTimePeriod also has a list of choices in one of the attributes so I would expect it to populate the database there as well.
python django django-models django-forms
python django django-models django-forms
edited Nov 26 '18 at 20:38
exceed
asked Nov 26 '18 at 20:26
exceedexceed
8910
8910
2
This has nothing to do with the database tables. In fact for most database engines, it never stores the choices at the database level. The choices are typically only verified, etc. at Django level.
– Willem Van Onsem
Nov 26 '18 at 20:29
Can you share a sampleModelFormyou use?
– Willem Van Onsem
Nov 26 '18 at 20:30
Hmm ok. When looking at the model where the choices are being populated in the database.. in the modelform code it refer to it directly while the ReportType does not have a modelform..it is just being linked from Report with a foreignkey. So i suppose you need to have a direct relationship here and that it doesnt work with tables that are just foreignkeys. Then you would need to write scripts that actually populate the database with the necessary values instead of just using the choices attribute for CharField.
– exceed
Nov 26 '18 at 20:45
it indeed stores the choices you make for records, but the column definition does not store the possible choices, these are typically not enforced at database level. If you use aModelFormthen normally it should work. If it works with a "vanilla"Form, you should add aChoiceField, etc.
– Willem Van Onsem
Nov 26 '18 at 20:46
I do not really understand why you here use aReportTypemodel with a choices. Typically you either add such field at theReportclass itself, or you allowReportTypeto have "free" text.
– Willem Van Onsem
Nov 26 '18 at 20:52
add a comment |
2
This has nothing to do with the database tables. In fact for most database engines, it never stores the choices at the database level. The choices are typically only verified, etc. at Django level.
– Willem Van Onsem
Nov 26 '18 at 20:29
Can you share a sampleModelFormyou use?
– Willem Van Onsem
Nov 26 '18 at 20:30
Hmm ok. When looking at the model where the choices are being populated in the database.. in the modelform code it refer to it directly while the ReportType does not have a modelform..it is just being linked from Report with a foreignkey. So i suppose you need to have a direct relationship here and that it doesnt work with tables that are just foreignkeys. Then you would need to write scripts that actually populate the database with the necessary values instead of just using the choices attribute for CharField.
– exceed
Nov 26 '18 at 20:45
it indeed stores the choices you make for records, but the column definition does not store the possible choices, these are typically not enforced at database level. If you use aModelFormthen normally it should work. If it works with a "vanilla"Form, you should add aChoiceField, etc.
– Willem Van Onsem
Nov 26 '18 at 20:46
I do not really understand why you here use aReportTypemodel with a choices. Typically you either add such field at theReportclass itself, or you allowReportTypeto have "free" text.
– Willem Van Onsem
Nov 26 '18 at 20:52
2
2
This has nothing to do with the database tables. In fact for most database engines, it never stores the choices at the database level. The choices are typically only verified, etc. at Django level.
– Willem Van Onsem
Nov 26 '18 at 20:29
This has nothing to do with the database tables. In fact for most database engines, it never stores the choices at the database level. The choices are typically only verified, etc. at Django level.
– Willem Van Onsem
Nov 26 '18 at 20:29
Can you share a sample
ModelForm you use?– Willem Van Onsem
Nov 26 '18 at 20:30
Can you share a sample
ModelForm you use?– Willem Van Onsem
Nov 26 '18 at 20:30
Hmm ok. When looking at the model where the choices are being populated in the database.. in the modelform code it refer to it directly while the ReportType does not have a modelform..it is just being linked from Report with a foreignkey. So i suppose you need to have a direct relationship here and that it doesnt work with tables that are just foreignkeys. Then you would need to write scripts that actually populate the database with the necessary values instead of just using the choices attribute for CharField.
– exceed
Nov 26 '18 at 20:45
Hmm ok. When looking at the model where the choices are being populated in the database.. in the modelform code it refer to it directly while the ReportType does not have a modelform..it is just being linked from Report with a foreignkey. So i suppose you need to have a direct relationship here and that it doesnt work with tables that are just foreignkeys. Then you would need to write scripts that actually populate the database with the necessary values instead of just using the choices attribute for CharField.
– exceed
Nov 26 '18 at 20:45
it indeed stores the choices you make for records, but the column definition does not store the possible choices, these are typically not enforced at database level. If you use a
ModelForm then normally it should work. If it works with a "vanilla" Form, you should add a ChoiceField, etc.– Willem Van Onsem
Nov 26 '18 at 20:46
it indeed stores the choices you make for records, but the column definition does not store the possible choices, these are typically not enforced at database level. If you use a
ModelForm then normally it should work. If it works with a "vanilla" Form, you should add a ChoiceField, etc.– Willem Van Onsem
Nov 26 '18 at 20:46
I do not really understand why you here use a
ReportType model with a choices. Typically you either add such field at the Report class itself, or you allow ReportType to have "free" text.– Willem Van Onsem
Nov 26 '18 at 20:52
I do not really understand why you here use a
ReportType model with a choices. Typically you either add such field at the Report class itself, or you allow ReportType to have "free" text.– Willem Van Onsem
Nov 26 '18 at 20:52
add a comment |
1 Answer
1
active
oldest
votes
You are misinterpreting how things work, the ModelForm for your Report model will look for ReportType instances to pre-populate the select in the html template. You need to create ReportType instances first.
Judging by your ReportType model and your question I assume you think that Django will create one ReportType instance for each of the REPORT_TYPE_CHOICES yet this is not the case. The choices attribute in a field is there for validation purposes. If you want to keep your models like they are now you'd need to create one instance of ReportType per REPORT_TYPE_CHOICES value.
Now, unless you have a good reason to have a ReportType model, you could change your Report model in the following way:
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="E" # note we use the Key here
)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53488522%2fdjango-model-choices-is-not-populating-the-database%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You are misinterpreting how things work, the ModelForm for your Report model will look for ReportType instances to pre-populate the select in the html template. You need to create ReportType instances first.
Judging by your ReportType model and your question I assume you think that Django will create one ReportType instance for each of the REPORT_TYPE_CHOICES yet this is not the case. The choices attribute in a field is there for validation purposes. If you want to keep your models like they are now you'd need to create one instance of ReportType per REPORT_TYPE_CHOICES value.
Now, unless you have a good reason to have a ReportType model, you could change your Report model in the following way:
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="E" # note we use the Key here
)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
add a comment |
You are misinterpreting how things work, the ModelForm for your Report model will look for ReportType instances to pre-populate the select in the html template. You need to create ReportType instances first.
Judging by your ReportType model and your question I assume you think that Django will create one ReportType instance for each of the REPORT_TYPE_CHOICES yet this is not the case. The choices attribute in a field is there for validation purposes. If you want to keep your models like they are now you'd need to create one instance of ReportType per REPORT_TYPE_CHOICES value.
Now, unless you have a good reason to have a ReportType model, you could change your Report model in the following way:
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="E" # note we use the Key here
)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
add a comment |
You are misinterpreting how things work, the ModelForm for your Report model will look for ReportType instances to pre-populate the select in the html template. You need to create ReportType instances first.
Judging by your ReportType model and your question I assume you think that Django will create one ReportType instance for each of the REPORT_TYPE_CHOICES yet this is not the case. The choices attribute in a field is there for validation purposes. If you want to keep your models like they are now you'd need to create one instance of ReportType per REPORT_TYPE_CHOICES value.
Now, unless you have a good reason to have a ReportType model, you could change your Report model in the following way:
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="E" # note we use the Key here
)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
You are misinterpreting how things work, the ModelForm for your Report model will look for ReportType instances to pre-populate the select in the html template. You need to create ReportType instances first.
Judging by your ReportType model and your question I assume you think that Django will create one ReportType instance for each of the REPORT_TYPE_CHOICES yet this is not the case. The choices attribute in a field is there for validation purposes. If you want to keep your models like they are now you'd need to create one instance of ReportType per REPORT_TYPE_CHOICES value.
Now, unless you have a good reason to have a ReportType model, you could change your Report model in the following way:
REPORT_TYPE_CHOICES = (
('E', 'Earnings'),
('MA', 'Monthly announcement'),
('WA', 'Weekly announcement'),
('SA', 'Sales announcement'),
)
class Report(models.Model):
profile = models.ForeignKey(Profile, on_delete=models.CASCADE)
name = models.CharField(max_length=200)
report_type = models.CharField(
max_length=50,
choices=REPORT_TYPE_CHOICES,
default="E" # note we use the Key here
)
time_period = models.ForeignKey(ReportTimePeriod)
link = models.URLField(max_length=500)
report_conclusion = models.CharField(max_length=500, default="No conclusion yet")
market_reaction = models.CharField(max_length=500, default="No market reaction yet")
answered Nov 26 '18 at 20:56
ivissaniivissani
84168
84168
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53488522%2fdjango-model-choices-is-not-populating-the-database%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
This has nothing to do with the database tables. In fact for most database engines, it never stores the choices at the database level. The choices are typically only verified, etc. at Django level.
– Willem Van Onsem
Nov 26 '18 at 20:29
Can you share a sample
ModelFormyou use?– Willem Van Onsem
Nov 26 '18 at 20:30
Hmm ok. When looking at the model where the choices are being populated in the database.. in the modelform code it refer to it directly while the ReportType does not have a modelform..it is just being linked from Report with a foreignkey. So i suppose you need to have a direct relationship here and that it doesnt work with tables that are just foreignkeys. Then you would need to write scripts that actually populate the database with the necessary values instead of just using the choices attribute for CharField.
– exceed
Nov 26 '18 at 20:45
it indeed stores the choices you make for records, but the column definition does not store the possible choices, these are typically not enforced at database level. If you use a
ModelFormthen normally it should work. If it works with a "vanilla"Form, you should add aChoiceField, etc.– Willem Van Onsem
Nov 26 '18 at 20:46
I do not really understand why you here use a
ReportTypemodel with a choices. Typically you either add such field at theReportclass itself, or you allowReportTypeto have "free" text.– Willem Van Onsem
Nov 26 '18 at 20:52