On Saturday 19 December 2015 11:23:17 Erik Cederstrand wrote:
> > Den 19. dec. 2015 kl. 16.01 skrev Aymeric Augustin
> > <aymeric.augus...@polytechnique.org>:
> >
> > 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.
