I thought the whole point of an ORM was to abstract away differences between backends... That's why this seems like a bug to me.
On Wednesday, January 4, 2017 at 1:02:07 PM UTC+1, Avraham Serour wrote: > > Well this is the reality right now, if you think the framework is acting > wrong you may file a bug report. > > In my opinion the wrong side of the equation is you, the framework is just > passing the value you assigned, the ORM tries to make a consistent API > between backends but I wouldn't really expect the same behaviour from all > backends, after all they are different backends, they will have different > bugs, performance and ultimately different behaviour > > On Wed, Jan 4, 2017 at 1:47 PM, <[email protected] <javascript:>> wrote: > >> 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]> 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]. >>>> 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/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] <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/e2f9758c-fc43-41c3-b7d2-fdbd8cc2998f%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-users/e2f9758c-fc43-41c3-b7d2-fdbd8cc2998f%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/a4113f3e-3166-453f-ae1e-82158b9d9b1b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
