is support for old cx_Oracle versions needed?

[Tim Graham]

The docs say, "Version 4.3.1 or higher of the `cx_Oracle`_ Python driver is required, although we recommend version 5.1.3 or later as these versions support Python 3." The advise of "4.3.1 or higher" hasn't changed since 2007 (Django 1.0).

Shai contributed a bug fix for timedelta handling in cx_Oracle which is released in 5.2. Would there be any problem in bumping the required version of cx_Oracle and removing the workaround in Django [0]? I spotted at least a few other workarounds for bugs in cx_Oracle 4.x that could also be removed.

As far as I know, the main reason for supporting older versions of other drivers such as psycopg2 is to accommodate developers who want to use their OS packages rather than installing via pip. I'm not sure if there's an analogous situation for cx_Oracle and/or if upgrading presents some other challenges.

Our CI server is always using the latest release of cx_Oracle so it's unknown if older versions actually work.

Josh says:

"there's quite a lot of fixes and features in newer cx_Oracle versions that would help us out. Some:

• Explicit support for service_name as well as SID (5.1.1)
• Support for Oracle 12c (5.1.3)
• Support for python 3.5 (5.2.1)

I'm not aware of any reasons for maintaining support for version 4 of cx_Oracle."

---

[0] https://github.com/django/django/pull/7721
[1] workarounds for old cx_Oracle bugs
https://github.com/django/django/commit/1aa48898085ea16915877cc139e238a74e3f554b - cx_Oracle <= 4.4.0 wrongly raises a DatabaseError for ORA-01400.
https://github.com/django/django/commit/c5d3a925c7285df4133cdb028f3a4bf44fd01e59 - stmtcachesize is available only in 4.3.2 and up.

[Josh Smeaton]

I'm unsure how others typically install cx_Oracle, but when I had to do it, it involved downloading and installing proprietary oracle drivers, making sure the headers were linked to the correct place, and then using pip. I don't think licensing allows OS maintainers to package up cx_Oracle and its dependencies, so I'd like to hear from others if this is a thing.

It's also worth noting that from Django 2.0, we'll have to depend on >= 5.2.1 for the python support, as that is when we drop support for all pythons < 3.5. 

Personally, I think the impact of a minimum version bump to 5.2 would be low as most should be running on 5.1.3 or greater anyway.

[Shai Berger]

On Thursday 22 December 2016 00:07:05 Josh Smeaton wrote:
> I don't think licensing allows OS maintainers to package up cx_Oracle and
> its dependencies, so I'd like to hear from others if this is a thing.
>

I checked and cx_Oracle does not seem to be packaged in Debian (at least not
in its free repos), although Oracle drivers for other languages (Perl and
Common Lisp) are (in the "contrib" part, where you can put free software which
depends on proprietary). So, it actually may be an issue.

>
> Personally, I think the impact of a minimum version bump to 5.2 would be
> low as most should be running on 5.1.3 or greater anyway.
>

I agree. As far as I'm aware, at least part of the appeal of the old cx_Oracle
versions was support of old Oracle versions. A couple of years ago we set a
firm policy of dropping support for EOL'd product versions, and I think even
Oracle 11.2 is getting there soon, so that's no longer an issue.

Shai.

[Tim Graham]

I created a ticket and PR to bump the minimum cx_oracle version to 5.2.

https://code.djangoproject.com/ticket/27649
https://github.com/django/django/pull/7752