Supporting Oracle's renamed cx_Oracle driver in Django

2022-05-27 Thread Christopher Jones
A new, major Python cx_Oracle driver release is available 

 
and it comes with a brand new name: *python-oracledb* 
.  At run time, the module name 
of the package is now '*oracledb*'.

With the aid of a shim to map the name space back to cx_Oracle, we  
(Oracle) have run Django's tests successfully:

import sys
import oracledb
oracledb.version = "8.3.0"
sys.modules["cx_Oracle"] = oracledb
import cx_Oracle

But the new name space could do with some love to add Django support so the 
shim isn't needed.  

The ideas below are from the developers who worked on the python-oracledb 
project and tested Django.

For background, python-oracledb is now a Thin driver by default - it 
connects directly to Oracle Database without always needing Oracle Client 
libraries.  A “Thick” mode can be optionally enabled by an application call 
to init_oracle_client(). This mode has similar functionality to cx_Oracle 
and supports Oracle Database features that extend the Python DB API.  To 
use this mode, the Oracle Client libraries such as from Oracle Instant 
Client must be installed separately - same as with cx_Oracle.

There are three main topics for python-oracledb support in Django.

*1. Supporting the new name space*

There are a couple of options:

1a. What about completely replacing cx_Oracle with python-oracledb 
(oracledb)? Python-oracledb is just a major release of cx_Oracle with a new 
name.  We have run Django tests.  The new driver is 'thin' by default so 
it's easier for almost everyone to use.

1b. Alternatively a configuration option needs to allow either cx_Oracle or 
python oracledb to be used.  Perhaps this could be done by creating 
separate sub-modules, one for each name space, inside 
django.db.backends.oracle? If so, then the ‘ENGINE’ values could be:

   django.db.backends.oracle.oracledb

or

   django.db.backends.oracle.cx_Oracle

*2. Letting users choose whether to use python-oracledb Thin or Thick modes*

The default in python-oracledb is Thin mode, which will suit almost all 
users.  But other people may want features available only in Thick mode.

Thick mode can only be enabled with an explicit call to init_oracle_client() 
before any connection is created.  Some users will need to pass a lib_dir 
argument to it.

Some options:

2a. It could be documented that users need to explicitly call 
init_oracle_client() in their own code.  This may be easiest.

2b. Or how about adding a new parameter, say ‘DRIVER_MODE’ or simply 
‘MODE’, in settings.dict to allow users to use the ‘Thick’ mode of 
python-oracledb?  Django would need to make a call to init_oracle_client() 
internally.  This would need to take an optional parameter to be passed as 
the lib_dir argument to init_oracle_client()

*3. Supporting some new connection parameters and using service names 
instead of SIDs*

One new feature of the python-oracledb driver are additional connect() 
keyword arguments like hostname, port, service_name, tcp_connect_timeout.  
(The makedsn() function is now deprecated in python-oracle because of this 
change.)  How can new parameters best be passed to python-oracledb?

It may also be time to modernize some existing connection code in Django 
for Oracle. For example, to more obviously connect using database 'service 
names' instead of SIDs (which were obsoleted decades ago).  We recommend 
using service names instead of SIDs so that various database properties 
like Oracle's Application Continuity feature can be enabled.

It would be nice if apps could do something like:

   DATABASES = {
   'default': {
   'ENGINE': 'django.db.backends.oracle',
   'USER': 'scott',
   'PASSWORD': '',
   'OPTIONS': {
   'host': 'example.com',
   'port': 1521,
   'service_name': 'orclpdb',
   'tcp_connect_timeout': 10,
  },
   }
   }

We have tossed around various ideas about all these but know it's best to 
get Django community involvement early about the design.

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0de59a35-4630-460d-984d-2ace3dac2f1an%40googlegroups.com.


Re: Supporting Oracle's renamed cx_Oracle driver in Django

2022-06-07 Thread Christopher Jones
> I agree with Florian, I'd prefer adding support for *python-oracledb* in 
Django 4.1 and immediately deprecate using *cx_Oracle *(will be removed in 
Django 5.0).

That sounds fair.  The cx_Oracle namespace won't have any substantive 
changes; maybe some new wheels for Python 3.11, and any critical bug 
fixes.  All progress will be under the new name.

The question is how to add support cleanly so that both names are supported 
in 4.1?  Is there a preference?  Particularly how can it be be done to 
reuse code without (temporary) duplication?

Regarding connection options, yes some things are supported with the Easy 
Connect Plus syntax.  There are some connection properties that aren't 
supported, e.g  application contexts (this was also true of cx_Oracle). And 
maybe more in future depending what users ask for. A generic way to set 
these, e.g with OPTIONS is a good direction.  

Chris

On Tuesday, May 31, 2022 at 7:04:07 PM UTC+10 Mariusz Felisiak wrote:

> I agree with Florian, I'd prefer adding support for *python-oracledb* in 
> Django 4.1 and immediately deprecate using *cx_Oracle *(will be removed 
> in Django 5.0).
>
> *3. Supporting some new connection parameters and using service names 
>>> instead of SIDs*
>>>
>>> One new feature of the python-oracledb driver are additional connect() 
>>> keyword arguments like hostname, port, service_name, tcp_connect_timeout.  
>>> (The makedsn() function is now deprecated in python-oracle because of 
>>> this change.)  How can new parameters best be passed to python-oracledb?
>>>
>>
> As far as I'm aware this is already supported with an easy connect string 
> or full DSN in *NAME*, see docs 
> 
> .
>
> Best,
> Mariusz
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6f449d19-8560-4f29-8eb9-61e5aea63b45n%40googlegroups.com.


Re: Supporting Oracle's renamed cx_Oracle driver in Django

2022-06-08 Thread Christopher Jones


On Tuesday, June 7, 2022 at 7:36:38 PM UTC+10 f.apo...@gmail.com wrote:

> Hi Chris,
>
> On Tuesday, June 7, 2022 at 11:30:46 AM UTC+2 christopher@gmail.com 
> wrote:
>
>> The question is how to add support cleanly so that both names are 
>> supported in 4.1?  Is there a preference?  Particularly how can it be be 
>> done to reuse code without (temporary) duplication?
>>
>
> Good question, no idea :) I am having the same problem with psycopg3 and 
> this is what I did 
> https://github.com/django/django/pull/15687/files#diff-01f6880f77beca32ee83e011072ba73dc7eed7f9f3efdebd935af693a4fac7b3
>  
> -- basically I added a compatibility module which does imports from the 
> respective locations, with the idea of being able to simply run sed over 
> this in the future. I know this isn't much of an answer and the differences 
> between psycopg2 & 3 are rather minimal but maybe a similar approach is 
> viable for oracle as well?
>  
>
>> Regarding connection options, yes some things are supported with the Easy 
>> Connect Plus syntax.  There are some connection properties that aren't 
>> supported, e.g  application contexts (this was also true of cx_Oracle). And 
>> maybe more in future depending what users ask for. A generic way to set 
>> these, e.g with OPTIONS is a good direction.  
>>
>
> Yes, I'd use the existing backends as guidelines, common stuff like HOST 
> etc fits into the toplevel imo.
>
> Cheers,
> Florian
>

Thanks Florian - we'll try out some ideas.

Chris 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/691cf81d-493d-428b-9f3b-cc2b48a9813cn%40googlegroups.com.


Re: Proposing the removal of Oracle from the Django supported backend databases

2023-08-03 Thread Christopher Jones
On Thu, Aug 3, 2023 at 6:26 PM Paolo Melchiorre 
wrote:

> Hi all,
> I wanted to share the frustration of seeing yet another great new ORM
> feature blocked due to Oracle compatibility:
> https://github.com/django/django/pull/16417
>
> In the past, I too have had to put a lot of effort trying to make a PR
> compatible with Oracle, making the overall contributing experience
> much less pleasant and holding me back from contributing, especially
> in the early days.
>
> Over the last few months, I've tried to encourage newcomers and young
> users to contribute to Django and they almost always ran into the need
> to provide compatibility to Oracle, so much so that they eventually
> gave up contributing.
>
> I stress that I am absolutely not criticizing the contributors (very
> few) in the community who help overcome the difficulties with Oracle.
>
> The point is that I think Oracle is a historical anomaly among the
> database backends supported by Django because it is the only one that
> is not Open Source, it has irrelevant usage numbers (see Django
> Developers Survey 2022 Results
>
> https://lp.jetbrains.com/django-developer-survey-2022/#horizontal-bar-chart-862
> )
> and the company that earns from it does not contribute in any way to
> its maintenance or support (see Carlton Gibson keynote at PyCon Italia
> 2023 https://youtu.be/AHjnGtaWDjU?t=836)
>
> To add to all this we consider that developing for Oracle is much more
> difficult than for the other Open Source databases supported by Django
> and above all the new contributors to the ORM have a frustrating
> experience and therefore they are less and less.
>
> I, therefore, suggest that we start a discussion on removing Oracle
> from supported databases.
>
> Ciao,
> Paolo
> --
> Paolo Melchiorre
>
> https://www.paulox.net
>
>
We (Oracle0 would like to improve Oracle support in Django and intend to
contribute. However the PR to add support for the latest Oracle driver is
blocked because debugging information about a test failure isn't available,
and the failure isn't seen by us. If that can be overcome, then we can make
headway.
Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPEpGM9%3D0iPJA-JHAfRtf0s1FLZEcRkL_j5En4y1nD584658kQ%40mail.gmail.com.