Re: [Question] MySQL Microseconds stripping

2016-02-11 Thread Adam Johnson
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

Re: [Question] MySQL Microseconds stripping

2016-02-05 Thread Adam Johnson
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

Re: [Question] MySQL Microseconds stripping

2015-12-21 Thread Cristiano Coelho
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

Re: [Question] MySQL Microseconds stripping

2015-12-21 Thread Josh Smeaton
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

Re: [Question] MySQL Microseconds stripping

2015-12-21 Thread Aymeric Augustin
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 >

Re: [Question] MySQL Microseconds stripping

2015-12-20 Thread 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 probably a little performance impact ?). I think the documented change might need a

Re: [Question] MySQL Microseconds stripping

2015-12-20 Thread Shai Berger
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

Re: [Question] MySQL Microseconds stripping

2015-12-20 Thread Erik Cederstrand
> 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

Re: [Question] MySQL Microseconds stripping

2015-12-19 Thread Cristiano Coelho
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

Re: [Question] MySQL Microseconds stripping

2015-12-19 Thread Shai Berger
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

Re: [Question] MySQL Microseconds stripping

2015-12-19 Thread Erik Cederstrand
> 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

Re: [Question] MySQL Microseconds stripping

2015-12-19 Thread Aymeric Augustin
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,

Re: [Question] MySQL Microseconds stripping

2015-12-19 Thread Erik Cederstrand
> 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

Re: [Question] MySQL Microseconds stripping

2015-12-18 Thread 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 1.7, so it is actually a datetime(0) column) and I would like to keep it that way, however,

Re: [Question] MySQL Microseconds stripping

2015-12-18 Thread Erik Cederstrand
> 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

Re: [Question] MySQL Microseconds stripping

2015-12-18 Thread Cristiano Coelho
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

[Question] MySQL Microseconds stripping

2015-12-18 Thread 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 with micro second precision on mysql, but the queries are sent with them. As I see it, my only