> Den 20. dec. 2015 kl. 01.04 skrev Cristiano Coelho <cristianocc...@gmail.com>: > > 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/0001EA1D-0B44-4CC8-AC6B-A80F3B14F943%40cederstrand.dk. For more options, visit https://groups.google.com/d/optout.
