#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 , 12 years ago
| Owner: | changed from to |
|---|---|
| Severity: | Normal → Release blocker |
| Status: | new → assigned |
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 12 years ago
comment:4 by , 12 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 , 12 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 , 12 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:7 by , 12 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?