Instead of default='17/06/2017', you should write default=datetime(2017, 6, 17). The bug in Django (if it is a bug, and I think it is) is that it does not require you to do so. There's probably a reason for it, but I don't really know..
Regards, Antonis Antonis Christofides http://djangodeployment.com On 01/04/2017 03:10 PM, [email protected] wrote: > 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: > | > Operationsto perform: Applyall > > migrations:activities,addressbook,admin,auth,contenttypes,sessions,users > Runningmigrations: > Applyingactivities.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,inexecute_from_command_line utility.execute() > > File"/webapps/mzg/venv/lib/python3.5/site-packages/django/core/management/__init__.py",line > 359,inexecute > 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,inrun_from_argv self.execute(*args,**cmd_options) > > File"/webapps/mzg/venv/lib/python3.5/site-packages/django/core/management/base.py",line > 345,inexecute output =self.handle(*args,**options) > > File"/webapps/mzg/venv/lib/python3.5/site-packages/django/core/management/commands/migrate.py",line > 204,inhandle fake_initial=fake_initial, > > File"/webapps/mzg/venv/lib/python3.5/site-packages/django/db/migrations/executor.py",line > 115,inmigrate 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,inapply_migration state > =migration.apply(state,schema_editor) > > File"/webapps/mzg/venv/lib/python3.5/site-packages/django/db/migrations/migration.py",line > 129,inapply > > 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,indatabase_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,inalter_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,ineffective_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,inget_db_prep_save prepared=False) > > File"/webapps/mzg/venv/lib/python3.5/site-packages/django/db/models/fields/__init__.py",line > 1280,inget_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,inget_prep_value returnself.to_python(value) > > File"/webapps/mzg/venv/lib/python3.5/site-packages/django/db/models/fields/__init__.py",line > 1250,into_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] > this group at > https://groups.google.com/group/django-users > <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 > <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 > <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 > <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 > <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 > <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] > <mailto:[email protected]>. To post to this group, > send email to [email protected] > <mailto:[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 > <https://groups.google.com/d/msgid/django-users/a4113f3e-3166-453f-ae1e-82158b9d9b1b%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/918d7b4b-d36a-2764-c89b-bb6bd5880dea%40djangodeployment.com. For more options, visit https://groups.google.com/d/optout.
