The fact that some backends are more forgiving is exactly my point. Maybe the migrations engine should always force a datetime object (or at least a YYYY-MM-DD notation) to make it work consistently on all backends.
On Wednesday, January 4, 2017 at 11:35:38 AM UTC+1, Avraham Serour wrote: > > DateField is a representation of datetime.date, so you should assign a > date object and not a string, sqlite is more forgiving and doesn't complain > so much in many cases > > On Wed, Jan 4, 2017 at 12:13 AM, <[email protected] <javascript:>> wrote: > >> 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. >> >> >> On Tuesday, January 3, 2017 at 2:17:36 PM UTC+1, Avraham Serour wrote: >>> >>> please post your migration file and the error >>> >>> On Tue, Jan 3, 2017 at 12:00 PM, <[email protected]> wrote: >>> >>>> I recently set a default value in my local date format on a >>>> DateTimeField while I was using SQLite. The migration ran fine on my >>>> SQLite >>>> dev database, but when trying to apply the migration on my production >>>> Postgres database I got an error saying that a default value for >>>> DateTimeField must be in the format of 'YYYY-MM-DD'. Wouldn't it be >>>> prudent >>>> to force users to always specify the default value in the 'YYYY-MM-DD' >>>> format to avoid this problem of portability? (Not sure how MySQL handles >>>> it) >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/django-users. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-users/4f8e0aad-9c6e-45c5-a476-22f604584b0a%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-users/4f8e0aad-9c6e-45c5-a476-22f604584b0a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/562fac5e-de18-4eb4-b90a-3121f43c29bc%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-users/562fac5e-de18-4eb4-b90a-3121f43c29bc%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e2f9758c-fc43-41c3-b7d2-fdbd8cc2998f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
