#22363 closed Bug (fixed)
User provided one-off default date and datetime are not correctly serialized
Reported by: | linovia | Owned by: | Simon Charette |
---|---|---|---|
Component: | Migrations | Version: | 1.7-beta-1 |
Severity: | Release blocker | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
While playing with Django 1.7 I noticed there was an issue with some generated migrations.
I had a model to which I added:
some_date = models.DateField()
I ran the makemigration and it prompted me to enter a default value:
$ python manage.py makemigrations You are trying to add a non-nullable field 'some_date' to post without a default; we can't do that (the database needs something to populate existing rows). Please select a fix: 1) Provide a one-off default now (will be set on all existing rows) 2) Quit, and let me add a default in models.py Select an option: 1 Please enter the default value now, as valid Python The datetime module is available, so you can do e.g. datetime.date.today() >>> datetime.date.today() Migrations for 'blog': 0006_post_some_date.py: - Add field some_date to post
It created the following migration:
# encoding: utf8 from django.db import models, migrations import datetime class Migration(migrations.Migration): dependencies = [ ('blog', '0005_post_image_big'), ] operations = [ migrations.AddField( model_name='post', name='some_date', field=models.DateField(default=date(2014, 3, 31)), preserve_default=False, ), ]
Now if you look at the default, it uses date(...) while it only imports datetime and thus will not be able to run.
Change History (8)
comment:1 by , 11 years ago
Owner: | changed from | to
---|---|
Severity: | Normal → Release blocker |
Status: | new → assigned |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 11 years ago
comment:3 by , 11 years ago
I just gave it a try and it works.
comment:4 by , 11 years ago
I just ran into this issue as well. I wouldn't call it a namespacing problem, though... the generated migration is just leaving off the datetime module name when trying to set datetime defaults.
comment:5 by , 11 years ago
Summary: | namespace issues with date when used as default value → User provided one-off default date and datetime are not correctly serialized |
---|
Adjusted the ticket summary to reflect the actual issue.
comment:6 by , 11 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:7 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Created a PR with a fix.
Could you confirm re-creating a the faulty migration with the applied patch solves your issue?