Re: [Django] #27684: Migrations accept default value for DateField that are not portable to all backends

2017-01-04 Thread Django 
#27684: Migrations accept default value for DateField that are not portable to 
all
backends
-+-
 Reporter:  voodoo-burger|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  Migrations => Database layer (models, ORM)


Comment:

 As Avraham mentioned on the django-users thread, `DateField` is a
 representation of `datetime.date`, so the `default` should be a `date`
 object and not a string. I'm going to close this as a duplicate of #25417
 since this is the essentially the same problem as reported there, just
 applied to a different field.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.c16533e908fb7d420659b3a502b5f16a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27684: Migrations accept default value for DateField that are not portable to all backends

2017-01-04 Thread Django 
#27684: Migrations accept default value for DateField that are not portable to 
all
backends
---+--
 Reporter:  voodoo-burger  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by voodoo-burger):

 Replying to [comment:1 Tim Graham]:
 > We tried to add a system check to validate model field defaults in
 #25417 but failed to do so due to backwards compatibility. I'm unsure if
 it's worth trying to make a similar change here given it will likely break
 backwards-compatibility for some users who may be using this technique and
 only care about supporting some databases.

 How about a warning then when someone uses a notation other than -MM-
 DD?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.b90211a4d737b4eadec19fe1994fc19d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27684: Migrations accept default value for DateField that are not portable to all backends

2017-01-04 Thread Django 
#27684: Migrations accept default value for DateField that are not portable to 
all
backends
---+--
 Reporter:  voodoo-burger  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 We tried to add a system check to validate model field defaults in #25417
 but failed to do so due to backwards compatibility. I'm unsure if it's
 worth trying to make a similar change here given it will likely break
 backwards-compatibility for some users who may be using this technique and
 only care about supporting some databases.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.08ef955ae5bbc760f1d8d208e594ae7c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27684: Migrations accept default value for DateField that are not portable to all backends

2017-01-04 Thread Django 
#27684: Migrations accept default value for DateField that are not portable to 
all
backends
-+
   Reporter:  voodoo-burger  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Migrations |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 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 
 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 -MM-DD notatie opgegeven
 worden."]
 }}}

 The error says: "DATE" has an invalid date notation. It must be submitted
 as -MM-DD notation. Timezone/locale is Europe/Amsterdam in case that
 makes a difference.