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.
On Wednesday, January 4, 2017 at 3:59:52 PM UTC+1, Avraham Serour wrote: > > 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 < > [email protected] <javascript:>> 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, [email protected] <javascript:> 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]> 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: >>>>>> 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, <[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]. 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 >>>>>> [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/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 >>>> [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/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 >> [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. 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] <javascript:>. >> To post to this group, send email to [email protected] >> <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/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 [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/65ddba02-6cde-4e62-af9a-3a6747716040%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
