[Django] #27684: Migrations accept default value for DateField that are not portable to all backends
Django
backends
-----------------------------------------+------------------------
Reporter: voodoo-burger | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
This field:
{{{
activity_date = models.DateField('Datum', default='17/06/2017')
}}}
Results in this migration:
{{{
class Migration(migrations.Migration):
dependencies = [
('activities', '0006_auto_20161231_1703'),
]
operations = [
migrations.AlterField(
model_name='activity',
name='activity_date',
field=models.DateField(default='17/06/2017',
verbose_name='Datum'),
),
]
}}}
Which works fine on SQLite but gives this error on Postgres:
{{{
Operations to perform:
Apply all migrations: activities, addressbook, admin, auth,
contenttypes, sessions, users
Running migrations:
Applying activities.0007_auto_20170103_2309...Traceback (most recent
call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/core/management/__init__.py", line 367, in
execute_from_command_line
utility.execute()
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/core/management/__init__.py", line 359, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/core/management/base.py", line 294, in run_from_argv
self.execute(*args, **cmd_options)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/core/management/base.py", line 345, in execute
output = self.handle(*args, **options)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/core/management/commands/migrate.py", line 204, in handle
fake_initial=fake_initial,
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/migrations/executor.py", line 115, in migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
fake_initial=fake_initial)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/migrations/executor.py", line 145, in
_migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake,
fake_initial=fake_initial)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/migrations/executor.py", line 244, in apply_migration
state = migration.apply(state, schema_editor)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/migrations/migration.py", line 129, in apply
operation.database_forwards(self.app_label, schema_editor, old_state,
project_state)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/migrations/operations/fields.py", line 204, in
database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/backends/base/schema.py", line 495, in alter_field
old_db_params, new_db_params, strict)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/backends/postgresql/schema.py", line 117, in
_alter_field
new_db_params, strict,
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/backends/base/schema.py", line 578, in _alter_field
new_default = self.effective_default(new_field)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/backends/base/schema.py", line 221, in
effective_default
default = field.get_db_prep_save(default, self.connection)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/models/fields/__init__.py", line 755, in
get_db_prep_save
prepared=False)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/models/fields/__init__.py", line 1280, in
get_db_prep_value
value = self.get_prep_value(value)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/models/fields/__init__.py", line 1275, in
get_prep_value
return self.to_python(value)
File "/webapps/mzg/venv/lib/python3.5/site-
packages/django/db/models/fields/__init__.py", line 1250, in to_python
params={'value': value},
django.core.exceptions.ValidationError: ["'17/06/2017' waarde heeft een
ongeldige datumnotatie. Deze moet in de YYYY-MM-DD notatie opgegeven
worden."]
}}}
The error says: "DATE" has an invalid date notation. It must be submitted
as YYYY-MM-DD notation. Timezone/locale is Europe/Amsterdam in case that
makes a difference.
It seems SQLite is more lax in what it accepts as a default value for a
DateField (a string in this case), but Postgres requires a string with
'YYYY-MM-DD' notation (or maybe a datetime.date object would also work).
It seems like a bug to me that the migrations engine would accept a
default value that is not usable on all backends.
Discussion on django-users: https://groups.google.com/forum/#!topic
/django-users/CrRdlgc9shQ
--
Ticket URL: <https://code.djangoproject.com/ticket/27684>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
backends
Reporter: voodoo-burger | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
We tried to add a system check to validate model field defaults in #25417
but failed to do so due to backwards compatibility. I'm unsure if it's
worth trying to make a similar change here given it will likely break
backwards-compatibility for some users who may be using this technique and
only care about supporting some databases.
--
Ticket URL: <https://code.djangoproject.com/ticket/27684#comment:1>
Django
backends
Reporter: voodoo-burger | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by voodoo-burger):
Replying to [comment:1 Tim Graham]:
> We tried to add a system check to validate model field defaults in
#25417 but failed to do so due to backwards compatibility. I'm unsure if
it's worth trying to make a similar change here given it will likely break
backwards-compatibility for some users who may be using this technique and
only care about supporting some databases.
How about a warning then when someone uses a notation other than YYYY-MM-
DD?
--
Ticket URL: <https://code.djangoproject.com/ticket/27684#comment:2>
Django
backends
Reporter: voodoo-burger | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: duplicate
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 Tim Graham):
* status: new => closed
* resolution: => duplicate
* component: Migrations => Database layer (models, ORM)
Comment:
As Avraham mentioned on the django-users thread, `DateField` is a
representation of `datetime.date`, so the `default` should be a `date`
object and not a string. I'm going to close this as a duplicate of #25417
since this is the essentially the same problem as reported there, just
applied to a different field.
--
Ticket URL: <https://code.djangoproject.com/ticket/27684#comment:3>