> 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 trun
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 t
> 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
h
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
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://djangodeploym
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
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 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
-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:
>
> D
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, wrote:
> This field:
>
> activity_date = models.DateField('Datum', default='17/06/2017')
>
>
>
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=
please post your migration file and the error
On Tue, Jan 3, 2017 at 12:00 PM, 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 productio
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
On Mon, 22 Aug 2016, Tim Graham wrote:
What do you mean by "not accepted"? Is there some error message? What you
wrote should work as far as I know.
Tim,
Yes, there was an error message that was not saved.
from datetime import date
That's probably the cause: my missing that import in
What do you mean by "not accepted"? Is there some error message? What you
wrote should work as far as I know.
from datetime import date
pub_date = models.DateField(default=date.today)
On Monday, August 22, 2016 at 7:04:11 PM UTC-4, Rich Shepard wrote:
>
> Reading the doc for DateField() I tri
On 23/08/2016 9:03 AM, Rich Shepard wrote:
Reading the doc for DateField() I tried to set the default as today's
date, but 'default=date.today' is not accepted.
If there is a way to set today's data as the default for a DateField()
please point me to the doc for it.
https://docs.djangoproj
Reading the doc for DateField() I tried to set the default as today's
date, but 'default=date.today' is not accepted.
If there is a way to set today's data as the default for a DateField()
please point me to the doc for it.
Thanks,
Rich
16 matches
Mail list logo
