Oracle DB backend should not overwrite NLS_LANG

[Manel Clos]

I already define the correct NLS_LANG for the database:

os.environNLS_LANG = "SPANISH_SPAIN.WE8ISO8859P1"

but then, it is overwritten here:
​http://code.djangoproject.com/browser/django/trunk/django/db/backends/oracle/base.py

Workaround: set NLS_LANG after database definition.

[Russell Keith-Magee]

I'm not sure this is the right thing to do -- Django has certain expectations of a UTF8 data source, so if you've got a different format in your database, you may encounter problems. However, I'm not sure of the specific implications of this when it comes to Oracle, so I'll leave this DDN.

[Erin Kelly]

NLS_LANG declares the client encoding, not the database encoding. UTF-8 is the correct client encoding for Django. The database encoding does not matter.

[Erin Kelly]

That was a bit terse, I apologize. I just want to add that since you didn't include any error message or failure that you're seeing, I'm assuming that you opened this ticket out of concern and not because you're experiencing any particular problem. If you are having an actual problem with the NLS_LANG setting, please reopen this ticket and be sure to include the full details of whatever you're running into.

[dchud@…]

Hi, I found this ticket after running into the same problem with django 1.4. I see that https://code.djangoproject.com/ticket/12714 was also closed as invalid.

I have the same problem in my code, and a fix that overrides the NLS_LANG value at the oracle driver level works for me. Patching the oracle driver to specify NLS_LANG = '.US7ASCII' works.

Our application is a django front-end to the oracle db underlying a proprietary software package (voyager) many university libraries like ours uses to manage our library catalogs. That package uses a convention of storing UTF8 but with the .US7ASCII encoding in oracle. It is a known design quirk in the community; the software vendor itself issues recommended access tools that explicitly force the ASCII encoding on the client side, otherwise UTF8 client connections return mangled data. This is a big, old application that will not likely change anytime soon.

I've documented the problem in a ticket for our code here:

​https://github.com/gwu-libraries/launchpad/issues/22

...my comments on the ticket include a link to this gist/paste that demonstrates the issue:

​https://gist.github.com/2960200

And the only way I can force the situation to work is to patch django's oracle driver (one-line patch noted in comments to ​https://github.com/gwu-libraries/launchpad/issues/22).

I would prefer not to ship an application that requires a patch to django, but we're going live with this in a few weeks so it'll have to do for now. Otherwise I would encourage a solution like the one advocated by the original poster in https://code.djangoproject.com/ticket/12714.

I understand your argument that utf8 all the way through is ideal and almost always correct; in my application, however oddly shaped the legacy app we're connecting to is, utf8 doesn't work, and I'd like to be able to specify NLS_LANG in the settings.

[Aymeric Augustin]

That package uses a convention of storing UTF8 but with the .US7ASCII encoding in oracle.

I'm sorry, but this isn't a use case we're interested in supporting explicitly in Django.

You can work around the problem by calling _setup_environment again when your application starts with the parameters you need.