> 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 On Wed, Jan 4, 2017 at 5:11 PM, <[email protected]> wrote: > 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]> 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] 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/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 >>>>>>> [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/ms >>>>> gid/django-users/e2f9758c-fc43-41c3-b7d2-fdbd8cc2998f%40goog >>>>> legroups.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...@googlegroups. >>> com. 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/ms >>> gid/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]. >>> 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/ms >>> gid/django-users/918d7b4b-d36a-2764-c89b-bb6bd5880dea%40djan >>> godeployment.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 > <https://groups.google.com/d/msgid/django-users/65ddba02-6cde-4e62-af9a-3a6747716040%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/CAFWa6tKZnuoM-tj8rzoxxCpGhhUHX1Oq9Z0A%2BfWpk6fECMgceg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
