[Django] #21312: models.DateTimeField with default=now: South migration fails
Django
-------------------------------+--------------------
Reporter: magopian | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.4
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
This is a problem that didn't happen on django1.6b4, but does on
django1.6c1:
Here's a snippet of the model:
{{{
from django.utils.timezone import now
@python_2_unicode_compatible
class User(AbstractBaseUser, PermissionsMixin):
"""TopChretien User, identified by its email."""
...
last_modified = models.DateTimeField(
_('last modification'), default=now, editable=False)
...
}}}
Here's the auto migration created by South when adding this new field to
the model:
{{{
import datetime
...
class Migration(SchemaMigration):
def forwards(self, orm):
# Adding field 'User.last_modified'
db.add_column(u'user_user', 'last_modified',
self.gf('django.db.models.fields.DateTimeField')(default=datetime.datetime.now),
keep_default=False)
}}}
And here's the result of running "manage.py migrate user" on django1.6b4:
{{{
$ ./manage.py migrate user
Running migrations for user:
- Migrating forwards to
0007_auto__add_field_user_last_modified__add_field_user_moderation_date__ad.
>
user:0007_auto__add_field_user_last_modified__add_field_user_moderation_date__ad
/home/mathieu/.virtualenvs/top/lib/python2.7/site-
packages/django/db/models/fields/__init__.py:901: RuntimeWarning:
DateTimeField received a naive datetime (2013-10-23 15:50:11.448018) while
time zone support is active.
RuntimeWarning)
- Loading initial data for user.
Installed 0 object(s) from 0 fixture(s)
}}}
And now on django1.6c1 (only the end of stacktrace, for readability,
please let me know if you need more):
{{{
File
"/home/mathieu/Dropbox/dev/topchretien/web/topchretien/user/migrations/0007_auto__add_field_user_moderation_date__add_field_user_moderator__add_fi.py",
line 14, in forwards
keep_default=False)
File "/home/mathieu/.virtualenvs/top/lib/python2.7/site-
packages/south/db/generic.py", line 47, in _cache_clear
return func(self, table, *args, **opts)
File "/home/mathieu/.virtualenvs/top/lib/python2.7/site-
packages/south/db/generic.py", line 411, in add_column
sql = self.column_sql(table_name, name, field)
File "/home/mathieu/.virtualenvs/top/lib/python2.7/site-
packages/south/db/generic.py", line 706, in column_sql
default = field.get_db_prep_save(default,
connection=self._get_connection())
File "/home/mathieu/.virtualenvs/top/lib/python2.7/site-
packages/django/db/models/fields/__init__.py", line 350, in
get_db_prep_save
prepared=False)
File "/home/mathieu/.virtualenvs/top/lib/python2.7/site-
packages/django/db/models/fields/__init__.py", line 911, in
get_db_prep_value
value = self.get_prep_value(value)
File "/home/mathieu/.virtualenvs/top/lib/python2.7/site-
packages/django/db/models/fields/__init__.py", line 902, in get_prep_value
(self.model.__name__, self.name, value),
AttributeError: 'DateTimeField' object has no attribute 'model'
}}}
The solution I used was to modify the South migration to get rid of the
warning (in Django1.6b4) and make it work correctly (in django1.6c1):
{{{
import django.utils.timezone
...
class Migration(SchemaMigration):
def forwards(self, orm):
# Adding field 'User.last_modified'
db.add_column(u'user_user', 'last_modified',
self.gf('django.db.models.fields.DateTimeField')(default=django.utils.timezone.now),
keep_default=False)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/21312>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: magopian | Owner: nobody
Type: Uncategorized | Status: new
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by mjtamlyn):
* needs_better_patch: => 0
* version: 1.4 => 1.6-beta-1
* severity: Normal => Release blocker
* needs_tests: => 0
* needs_docs: => 0
Comment:
I haven't checked this but marking as a release block as assuming it is
repeatable it certainly is a problem.
Do you perhaps have a minimal project set up to reproduce this? If not,
could you perhaps try to use `git bisect` to identify where between the
tags it broke? This would help us identify a fix faster.
--
Ticket URL: <https://code.djangoproject.com/ticket/21312#comment:1>
Django
Reporter: magopian | Owner: nobody
Type: Uncategorized | Status: new
Severity: Release blocker | Resolution:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by akaariai):
I've taken a quick look at this. This was introduced by
ddff6522fa72aacc7475ba5cd4bf8683ff12b8c7. The problem is that South
doesn't assign the field to any model. In Django self.model should always
exists (or at least always after app-loading).
I am not sure if this should be fixed in Django or in South. We can
definitely say that South relies on non-public usage of fields (after all
the only public way to use fields is to assign them to models in model
definition, and that means they will have self.model set). OTOH it seems
pretty simple to fix this in Django... I have generally favoured "private
API is private" -approach, so I am slightly in favour of that
interpretation.
--
Ticket URL: <https://code.djangoproject.com/ticket/21312#comment:2>
Django
Reporter: magopian | Owner: nobody
Type: Uncategorized | Status: new
(models, ORM) | 1.6-beta-1
Severity: Normal | Resolution:
Keywords: | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by shai):
* component: Uncategorized => Database layer (models, ORM)
* severity: Release blocker => Normal
Comment:
Based on Anssi's analysis, this is not a blocker for Django. Not sure it
is even a bug in Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/21312#comment:3>
Django
Reporter: magopian | Owner: nobody
Type: Uncategorized | Status: new
(models, ORM) | 1.6-beta-1
Severity: Normal | Resolution:
Keywords: | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
* cc: pronik (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/21312#comment:4>
Django
Reporter: magopian | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version:
(models, ORM) | 1.6-beta-1
Keywords: | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => invalid
Comment:
This is definitely a bug in South. Closing as invalid.
--
Ticket URL: <https://code.djangoproject.com/ticket/21312#comment:5>
Django
Reporter: magopian | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version:
(models, ORM) | 1.6-beta-1
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by jvzammit@…):
Did anyone report this in South? Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/21312#comment:6>
Django
Reporter: magopian | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version:
(models, ORM) | 1.6-beta-1
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by jvzammit@…):
Replying to [comment:6 jvzammit@…]:
> Did anyone report this in South? Thanks.
Please disregard my question; upgrading from south 0.8.2 to 0.8.3 solved
the problem.
--
Ticket URL: <https://code.djangoproject.com/ticket/21312#comment:7>