DateField default value in SQLite and Postgres

[jorr...@gmail.com]

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)

[Avraham Serour]

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+unsubscribe@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.
For more options, visit https://groups.google.com/d/optout.

[jorr...@gmail.com]

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.

[Avraham Serour]

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

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...@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.

[jorr...@gmail.com]

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.

[Avraham Serour]

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

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...@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/e2f9758c-fc43-41c3-b7d2-fdbd8cc2998f%40googlegroups.com.

[jorr...@gmail.com]

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.

[Antonis Christofides]

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

-- 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/a4113f3e-3166-453f-ae1e-82158b9d9b1b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[Avraham Serour]

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?

-- 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...@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.

--
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...@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.

[Antonis Christofides]

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?

Because attempting to interpret the string '17/06/2017' as a date is risky and will lead to trouble sooner or later, regardless the backend.

Antonis Christofides
http://djangodeployment.com

-- 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/CAFWa6tKHWTtEr2XjRXm520tz9sGT0Xaw9UwROt3EGKSJZGMbbg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.

[jorr...@gmail.com]

I use SQLite locally for development and Postgres in production. So when my migration runs fine locally I expect it to also work fine when I upload it 5 minutes later and try to apply it to my Postgres database.

-- 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/a4113f3e-3166-453f-ae1e-82158b9d9b1b%40googlegroups.com. 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.

[Avraham Serour]

> Because attempting to interpret the string '17/06/2017' as a date is risky and will lead to trouble sooner or later, regardless the backend.

This is a valid point, but I believe this is related to sqlite behaviour not the ORM using it.

mysql for example has its own bugs, there was one about truncating silently too long values assigned to a column. If I am using postgres why should my library limit me with mysql limitations?

> I use SQLite locally for development and Postgres in production. So when my migration runs fine locally I expect it to also work fine when I upload it 5 minutes later and try to apply it to my Postgres database.

This is a valid point to run tests, you really should have a gitlab, jenkins, travis whatever running tests because this is not the only difference between sqlite and postgres

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...@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/65ddba02-6cde-4e62-af9a-3a6747716040%40googlegroups.com.