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 little more of attention, and 
mention something about that any equality query will stop working if you 
either don't strip microseconds or update datetime columns to datetime(6) 
(and not even datetime(3) will work...)


El domingo, 20 de diciembre de 2015, 6:48:20 (UTC-3), Erik Cederstrand 
escribió:
>
>
> > Den 20. dec. 2015 kl. 01.04 skrev Cristiano Coelho <cristia...@gmail.com 
> <javascript:>>: 
> > 
> > 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? 
>
> While I understand that you'd like this to Just Work, you're sending 
> microseconds to the DB, knowing they will get lost, and expecting 
> comparisons to still work *with* microseconds. It's like expecting 12.34 == 
> int(12.34). 
>
> 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 with your code. Just dt.replace(microsecond=0) all date values before 
> you issue a .filter(), .save(), .update(), .raw() or whatever. 
>
> > Should I complain at mysql forums? 
>
> You could try, but since Oracle took over, all my reports have been 
> answered with WONTFIX. Anyway, it'll be months or years before you get 
> something you can install on your server. 
>
> Erik

-- 
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/fc7b50a9-def6-409b-b75c-9c40c616731d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to