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 <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, <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.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, <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/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 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 <javascript:>.
>> To post to this group, send email to django...@googlegroups.com
>> <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 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/a4113f3e-3166-453f-ae1e-82158b9d9b1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
