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)
follow-up: 2 comment:1 by , 8 years ago
comment:2 by , 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.
comment:3 by , 8 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.