Opened 8 years ago

Closed 8 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)

comment:1 by Tim Graham, 8 years ago

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.

in reply to:  1 comment:2 by voodoo-burger, 8 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.

Last edited 8 years ago by voodoo-burger (previous) (diff)

comment:3 by Tim Graham, 8 years ago

Component: MigrationsDatabase layer (models, ORM)
Resolution: duplicate
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top