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
mysql doesn't strip microseconds from the select as it does for the insert.
So this is really a mysql issue I guess...
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 the sql query
compile level.
This is really a bummer, because it seems like the only option is to
convert all my datetime columns into datetime(6), which increases the table
size and index by around 10%, for something I will never use.
Any other work around that can work with both normal and raw queries?
Should I complain at mysql forums?
El sábado, 19 de diciembre de 2015, 7:39:12 (UTC-3), Shai Berger escribió:
>
> On Saturday 19 December 2015 11:23:17 Erik Cederstrand wrote:
> > > Den 19. dec. 2015 kl. 16.01 skrev Aymeric Augustin
> > > <aymeric....@polytechnique.org <javascript:>>:
> > >
> > > 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 written to MySQL.
> > >
> > > That said, this change in Django sets up this trap for unsuspecting
> > > users. Providing a way for users to declare which fields use the old
> > > format won't work because of pluggable apps: they cannot know what
> > > version of MySQL their users were running when they first created a
> > > given datetime column. The best solution may be to provide a
> conversion
> > > script to upgrade all datetime columns from the old to the new format.
> >
> > One simple solution could be for Christiano to subclass the
> DateTimeField
> > to handle the microsecond precision explicitly. Something like this to
> > strip:
> >
> >
> > class DateTimeFieldWithPrecision(DateTimeField):
> > def __init__(self, *args, **kwargs):
> > self.precision = kwargs.get('precision', 6)
> > assert 0 <= self.precision <= 6
> > super().__init__(*args, **kwargs)
> >
> > def pre_save(self, model_instance, add):
> > dt = getattr(model_instance, self.attname)
> >
> dt.replace(microsecond=int(dt.microsecond/10**(6-self.precision)))
> > return dt
> >
>
> if I get the complaints correctly, something similar would need to be done
> when preparing a value for querying.
>
> More generally, I think Christiano just wants "the old field back" -- so,
> he
> has a use-case for a DateTimeField which explicitly does not use second
> fractions. We already have a DateTimeField which explicitly does not use
> day
> fractions (DateField), so I suppose we could find sense in that... We
> would
> typically suggest, as Erik implicitly did, that such field be done outside
> of
> Django, but the backward-compatibility issues mentioned by Aymeric make it
> quite plausible that such a field will be added to core or contrib.
>
> Shai.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/78d8b177-5dbe-4ad1-a86f-063332591da7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
