well the ORM does abstract the different API's for each backend, you may give an datetime object and it will take care to format to the appropriate thing the backend needs.
you are right that it does not check the type of the value passed, it is a valid point that the library should check the type, but on the other hand if one is using sqlite why enforce stricter rules than the backend I'm using just because one other backend has a problem with it? Also this is python, if it quacks like a duck then it is a duck, right? On Wed, Jan 4, 2017 at 3:24 PM, Antonis Christofides < anto...@djangodeployment.com> wrote: > 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 Christofideshttp://djangodeployment.com > > > On 01/04/2017 03:10 PM, jorrit...@gmail.com 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, <jorr...@gmail.com> 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, <jorr...@gmail.com> 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.Validat >>>>> ionError: ["'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, <jorr...@gmail.com> 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 >>>>>>> django-users...@googlegroups.com. To post to this group, send email >>>>>>> to django...@googlegroups.com. Visit this group at >>>>>>> https://groups.google.com/group/django-users. To view this >>>>>>> discussion on the web visit https://groups.google.com/d/ms >>>>>>> gid/django-users/4f8e0aad-9c6e-45c5-a476-22f604584b0a%40goog >>>>>>> legroups.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 >>>>> django-users...@googlegroups.com. To post to this group, send email >>>>> to django...@googlegroups.com. 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 django-users...@googlegroups. >>> com. To post to this group, send email to django...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/django-users. To >>> view this discussion on the web visit https://groups.google.com/d/ms >>> gid/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 django-users+unsubscribe@ > googlegroups.com. To post to this group, send email to > django-users@googlegroups.com. 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 django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > 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 > <https://groups.google.com/d/msgid/django-users/918d7b4b-d36a-2764-c89b-bb6bd5880dea%40djangodeployment.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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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/CAFWa6tKHWTtEr2XjRXm520tz9sGT0Xaw9UwROt3EGKSJZGMbbg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
