Opened 9 years ago
Closed 9 years ago
#27684 closed Bug (duplicate)
Migrations accept default value for DateField that are not portable to all backends
| Reported by: | voodoo-burger | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
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
Change History (3)
follow-up: 2 comment:1 by , 9 years ago
comment:2 by , 9 years ago
Replying to 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?
And I agree that backwards incompatible changes area PITA, but this "loophole" directly leads to broken migrations which doesn't seem like a good option either.
comment:3 by , 9 years ago
| Component: | Migrations → Database layer (models, ORM) |
|---|---|
| Resolution: | → duplicate |
| Status: | new → closed |
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.
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.