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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22363>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => assigned
* severity: Normal => Release blocker
* needs_better_patch: => 0
* needs_tests: => 0
* owner: linovia => charettes
* needs_docs: => 0
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/22363#comment:1>
Comment (by charettes):
Created a [https://github.com/django/django/pull/2502 PR] with a fix.
Could you confirm re-creating a the faulty migration with the applied
patch solves your issue?
--
Ticket URL: <https://code.djangoproject.com/ticket/22363#comment:2>
Comment (by linovia):
I just gave it a try and it works.
--
Ticket URL: <https://code.djangoproject.com/ticket/22363#comment:3>
Comment (by melinath):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22363#comment:4>
Comment (by charettes):
Adjusted the ticket summary to reflect the actual issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/22363#comment:5>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/22363#comment:6>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"074d3183d92cd5ed5da8f51e7048b12a96f55e0a"]:
{{{
#!CommitTicketReference repository=""
revision="074d3183d92cd5ed5da8f51e7048b12a96f55e0a"
Fixed #22363 -- Correctly serialize `django.utils.datetime_safe` objects.
Thanks to linovia for the report.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22363#comment:7>
Comment (by Simon Charette <charette.s@…>):
In [changeset:"7b3a221ad674ce74afd5db2a7dd0a0a3beb354ed"]:
{{{
#!CommitTicketReference repository=""
revision="7b3a221ad674ce74afd5db2a7dd0a0a3beb354ed"
[1.7.x] Fixed #22363 -- Correctly serialize `django.utils.datetime_safe`
objects.
Thanks to linovia for the report.
Backport of 074d3183d9 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22363#comment:8>