I've released the forementioned command as part of Django-MySQL, see here:
https://django-mysql.readthedocs.org/en/latest/management_commands/fix_datetime_columns.html
On Friday, February 5, 2016 at 1:03:42 PM UTC, Adam Johnson wrote:
>
> Hi,
>
> I've just finished converting all the datetime
Hi,
I've just finished converting all the datetime columns to datetime(6) in
our database after an upgrade to MySQL 5.6. We don't use Django migrations,
many of these were done manually with *pt-online-schema-change*. Just
catching up on this thread, throwing some ideas in.
Why not strip the
I think a simple setting allowing to use the old behaviour should be
enough, shouldn't it? How does it handle other db backends? I'm not sure if
oracle has an option for datetime precision, but if it does, it makes sense
to have a global setting for datetime precision, as right now you are
I think this is a fairly big oversight that should be fixed in the most
backwards compatible way, so users don't need to change their code, or only
have to change it minimally. I'm with Aymeric here. Does Django have
visibility of the field constraints at insert/select queryset time? Ideally
2015-12-20 22:57 GMT+01:00 Cristiano Coelho :
> Thanks for the suggestion, I think that work around might just add too
> much code, so I'm probably going the way of converting every datetime
> column of every table to datetime(6) and afford the extra storage (and
>
Thanks for the suggestion, I think that work around might just add too much
code, so I'm probably going the way of converting every datetime column of
every table to datetime(6) and afford the extra storage (and probably a
little performance impact ?).
I think the documented change might need a
On Sunday 20 December 2015 11:47:54 Erik Cederstrand wrote:
>
> Why not strip the microseconds explicitly as soon as you're handed a
> datetime with microseconds? That way you make it explicit that you really
> don't want microseconds. That's less head-scratching for the next person
> to work
> Den 20. dec. 2015 kl. 01.04 skrev Cristiano Coelho :
>
> About using a custom datetime field that strips microseconds, that won't work
> for raw queries I believe, not even .update statements as they ignore
> pre-save? As the stripping happens (or used to happen) at
Aymeric is right. I do an insert with microseconds (since that's what
django does right now) but mysql has the column defined as datetime(0), so
it just strips the microsecond part, however, when doing the select, I'm
expecting to get the value I have just inserted, but it doesn't work, since
On Saturday 19 December 2015 11:23:17 Erik Cederstrand wrote:
> > Den 19. dec. 2015 kl. 16.01 skrev Aymeric Augustin
> > :
> >
> > To be fair, this has a lot to do with MySQL’s lax approach to storing
> > data. There’s so many situations where it just throws
> Den 19. dec. 2015 kl. 16.01 skrev Aymeric Augustin
> :
>
> To be fair, this has a lot to do with MySQL’s lax approach to storing data.
> There’s so many situations where it just throws data away happily that one
> can’t really expect to read back data
Hello,
> On 19 déc. 2015, at 09:21, Erik Cederstrand wrote:
>
>> Den 19. dec. 2015 kl. 13.15 skrev Cristiano Coelho
>> :
>>
>> The issue is that every datetime column created has no microseconds (since
>> they were created with django 1.7,
> Den 19. dec. 2015 kl. 13.15 skrev Cristiano Coelho :
>
> Erik,
> I'm using MySQL 5.6.x and indeed it has microseconds support, but that's not
> the issue.
>
> The issue is that every datetime column created has no microseconds (since
> they were created with django
Erik,
I'm using MySQL 5.6.x and indeed it has microseconds support, but that's
not the issue.
The issue is that every datetime column created has no microseconds (since
they were created with django 1.7, so it is actually a datetime(0) column)
and I would like to keep it that way, however,
> Den 19. dec. 2015 kl. 07.52 skrev Cristiano Coelho :
>
> Hello,
>
> After django 1.8, the mysql backend no longer strips microseconds.
> This is giving me some issues when upgrading from 1.7 (I actually upgraded to
> 1.9 directly), since date times are not stored
Also I would like to add, that even if the mysql column is a 0 fractional
datetime column, and you send a datetime with some fraction in it (which is
what django does right now), it won't handle it correctly (ie trim the
fraction since the actual column has no fraction) but instead just try to
Hello,
After django 1.8, the mysql backend no longer strips microseconds.
This is giving me some issues when upgrading from 1.7 (I actually upgraded
to 1.9 directly), since date times are not stored with micro second
precision on mysql, but the queries are sent with them.
As I see it, my only
17 matches
Mail list logo