On 19 mai 2013, at 15:33, Shai Berger <[email protected]> wrote: > I was able to track the history of this function, into the mists of time. In > the beginning, code to cast strings into dates for Oracle was mixed in with > the general querying code. Then came the boulder-oracle-sprint of 2006-2007, > where, at some point, that piece of code was factored out to a module-level > function get_datetime_cast_sql(), which was defined in all backends as a > no-op > except Oracle; this was later refactored into the DatabaseOperations class we > know today. > > However, at about the same time that the DatabaseOperations was created, the > Oracle backend made another change: It started setting the session's datetime > format on login. This, as far as I understand, makes the special casting > operation redundant -- and current test results support my understanding. > > So -- I want to fix, now, the thing that was, well, not broken, but bent, in > 2007. And my question to you -- especially, those of you who participated in > the boulder sprint -- can you think of any reason why I shouldn't?
Based on the impressive amount of research you've performed, and on the facts you've found, I think you can go ahead and simplify the code. I'll review the patch if you want. Thanks for working on this. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
