On Apr 1, 9:10 pm, "Adam V." <[EMAIL PROTECTED]> wrote: > In DateTimeField.get_db_prep_save there is a hard-coded check for the > mysql backend, which drops the microseconds from the value. > > I'm working on an external MS SQL backend (django-mssql) and I'm > running into a different problem here. > > DateTimeFields are sent to queries as unicode which looks like: > u'2008-03-09 17:45:10.156000' > > MS SQL Server only accepts up to 3 digits in the decimal, so this > would work: > u'2008-03-09 17:45:10.156' > > I certainly don't want to cram a check for my external backend name > into django's core... but by the time the parameter is being processed > in the backend its already a string and I don't have a lot of > information about the fact that it's going to end up (say) being > inserted into a date field in the database. > > A patch to my backend is using a regex to find datetime patterns and > truncate them... except it would also truncate those patterns being > sent to string fields. Possibly an unlikely case, but I don't want to > knowingly munge data in hard to track ways. > > Would it make sense to have the DateTimeField use a back-end provided > munger in get_db_prep_save instead of the hardcoded mysql check, or is > that gross? Or is there a better way to handle this that I'm missing? > (Or do I just have to suck it up in my backend?) > > - Adam V.
Adam, I think that in the current situation the best way is to create a patch to Django core and distribute it with your backend or create the entire backend as a patch (that's exactly what I am going to do with Firebird database support in the nearest future). Too many things are hardcoded into Field class and management.sql/ management.validation with no way to customize it in the backend. Your current problem was solved with Firebird backend (that accepts only 4 digits for microseconds) by adding 'timestamp = timestamp[:24]' before passing it to database, thanks to the type_conv_in/ type_conv_out functionality in kinterbasdb package. I think that it's perfectly OK to distribute a patch to change the hardcoded functionality -- it's far better than trying to monkey-patch the code under active development. I also switched to queryset-refactor branch rescently -- it has some really great improvements for backend developers. Django devs are doing a great job. Hope this helps, -- Ivan Illarionov --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
