On 22 mai 2013, at 01:32, Shai Berger wrote:
> I guess we can get away with skipping deprecation cycles; but don't you
> think we should try to warn users who override it that it is no longer used?
We don't really have a process for that. Maintaining a database backend
for Django is a hard task
On Tuesday 21 May 2013 22:11:02 Aymeric Augustin wrote:
> On 19 mai 2013, at 15:33, Shai Berger wrote:
> >
> > 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 -- ca
Hi Ian,
Thanks for your insights.
On Tuesday 21 May 2013 23:22:14 Ian Kelly wrote:
>
> You may be right. One thing I would be concerned about is the
> reliability of only doing implicit date conversions. If you google
> for "ORA-01843" you can find a good number of forum posts that
> recommend
On Sun, May 19, 2013 at 7:33 AM, Shai Berger wrote:
> Hi,
>
> In my quest to solve Oracle bugs, I found the function datetime_cast_sql() in
> the Oracle backend. It causes a problem these days, because it gets in the way
> of querying a date as string (mydate__startswith='2005'). It is a function
On 19 mai 2013, at 15:33, Shai Berger 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 s
Hi,
In my quest to solve Oracle bugs, I found the function datetime_cast_sql() in
the Oracle backend. It causes a problem these days, because it gets in the way
of querying a date as string (mydate__startswith='2005'). It is a function
that is defined as a no-op in the base backend, and overrid
