looking up date as str (fails under Oracle, Ticket #20015)

[Shai Berger]

Hi django devs,

While going through Oracle bugs, I ran into the ticket in the subject[0]. The
problem there is that current code assumes that whenever we want to compare
anything (pretty much) against a datetime column, in any way, we'd like to
compare the column value and the given value as datetimes. Of course, in the
case of lookup_date_as_str -- lookup types like 'startswith' -- this is not
the case.

I want to fix things so that for the relevant lookup types, the comparison will
not try to force anything into a date. I see at least two ways to do that, but
they share ugliness: They take a place in general code which special-cases
datetimes, and add an extra special-casing for the lookup types. The fix (in
each of the ways I see) is less than 5 lines of code, but, euh.

So, two questions arise:

1) The fixes I see would affect all backends, but AFAIK only Oracle is reported
as failing the test; anyone wants to comment on this? Do all other backends
just not need a cast_to_date operation?

2) Should I fix it in the ugly ways, or look for a more general solution, which
will involve deeper changes?

Thanks,
Shai.

[0] https://code.djangoproject.com/ticket/20015

[Anssi Kääriäinen]

I don't think it is necessary to do deeper changes. My interpretation
of the current lookup system is that it has been stretched to its
limits and needs to be refactored. I intended to do that already for
the 1.6 release but ran out of steam.

Of course, if you want to do improvements to current code that isn't
forbidden... But don't feel obligated to do so.

I am not sure about question 1 except that changing the backend API to
make Oracle work is OK.

- Anssi

[Shai Berger]

I'm toying with a different solution now -- removing the date casting on Oracle
too. It passed the lookup tests, now I'm running the whole suite (that takes a
little time). After seeing that no other backend in core does it, and as we do
set the timestamp format, I wonder if it is really necessary. If that works,
it's a pretty solution that affects Oracle only.

Shai.

[Shai Berger]

On Saturday 18 May 2013 19:49:58 Shai Berger wrote:
>
> I'm toying with a different solution now -- removing the date casting on
> Oracle too. It passed the lookup tests, now I'm running the whole suite
> (that takes a little time). After seeing that no other backend in core
> does it, and as we do set the timestamp format, I wonder if it is really
> necessary. If that works, it's a pretty solution that affects Oracle only.
>

Running over the entire Django test-suite, the only difference that is made by
removing the cast-to-date on Oracle is that now test_lookup_date_as_str
passes; so I'm very much inclined to do that.

However, I have a little problem in my testing environment: I keep getting
"ora-01882 timezone region not found" for 5 TZ-related tests. As these are
all, of course, datetime-related tests, I'd like to get them to pass. They do
pass on our CI [0], and the mailing list includes mentions of running into
related problems. What I see when I investigate is: The test specifies the
timezone as "Africa/Nairobi", which would have been fine, exceot that by the
time it gets into the SQL to be executed, it is transformed to "EAT", which
(rightfully) triggers the error.

Florian, Aymeric, or any Django/Oracle user in Kenya: How did you overcome
this?

Thanks,
Shai.

[Shai Berger]

Oopsie:

On Sunday 19 May 2013 08:12:12 Shai Berger wrote:
> ...They do pass on our CI [0],...

http://ci.djangoproject.com/job/Django%20Oracle/lastCompletedBuild/database=oracle,python=python2.7/

Thanks,
Shai.

[Florian Apolloner]

Hi Shai

On Sunday, May 19, 2013 7:12:12 AM UTC+2, Shai Berger wrote:

Florian, Aymeric, or any Django/Oracle user in Kenya: How did you overcome
this?

I have no idea, I just bang my head against the CI till it works or falls completely apart  (well not really, but you get the gist ;)). I'll ask Aymeric when he shows up and get back to you.

Cheers,
Florian

[Aymeric Augustin]

On 19 mai 2013, at 07:12, Shai Berger <sh...@platonix.com> wrote:

> Florian, Aymeric, or any Django/Oracle user in Kenya: How did you overcome
> this?

Install pytz.

I recently skipped these tests on MySQL when pytz wasn't installed, I shall do the same for Oracle.

--
Aymeric.