Hi Chris, a thin client seems like great news to me :)
On Friday, May 27, 2022 at 3:05:51 PM UTC+2 christopher....@gmail.com wrote: > 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. > Assuming the differences between the two drivers are not to big I'd would be great if the existing backend would support both names for now. Then we can drop the cx_oracle imports relatively easily after a release or two. > 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 ... > I am against this, if python-oracledb is the new cx_oracle I guess cx_oracle won't really be developed anymore (correct me if I am wrong) and as such I do not see much point in supporting both. Oracle is a beast on it's own, one oracle driver to handle is more than enough :) *2. Letting users choose whether to use python-oracledb Thin or Thick modes* > > 2a. It could be documented that users need to explicitly call > init_oracle_client() in their own code. This may be easiest. > Would be fine for me if the testsuite passes with thin mode. > 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() > Should be fine I think, lets see what others think about that. But the config approach would certainly be the preferred way of doing things over the documentation approach (in the longrun at least). Then again I am not really sure which features thick mode offers and whether Django developers will actually need that often… You probably know that better than I do. *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? > I'd say use get_connection_params & get_new_connection https://github.com/django/django/blob/8c0886b068ba4e224dd78104b93c9638b860b398/django/db/backends/oracle/base.py#L245-L259 -- or do I miss something here. It would be nice if apps could do something like: > > DATABASES = { > 'default': { > 'ENGINE': 'django.db.backends.oracle', > 'USER': 'scott', > 'PASSWORD': 'XXXX', > 'OPTIONS': { > 'host': 'example.com', > 'port': 1521, > 'service_name': 'orclpdb', > 'tcp_connect_timeout': 10, > }, > } > } > I think obvious keys like host & port should be kept in the toplevel like we already do https://docs.djangoproject.com/en/4.0/ref/databases/#connecting-to-the-database-1 and the NAME could become the service_name (though I do see how this could clash with the current usage)? Then again we are not 100% consistent all the time here, so whatever feels more natural I guess? I hope this helps somewhat. Let us know if there is more you'd like to know. Cheers, Florian -- 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/9032cdc0-5c59-4df8-a595-820434b33cddn%40googlegroups.com.
