Opened 13 years ago

Closed 11 years ago

#15313 closed Uncategorized (wontfix)

Oracle DB backend should not overwrite NLS_LANG

Reported by: Manel Clos Owned by: nobody
Component: Database layer (models, ORM) Version: 1.2
Severity: Normal Keywords: oracle
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (7)

comment:1 by Russell Keith-Magee, 13 years ago

Keywords: oracle added
Triage Stage: UnreviewedDesign decision needed

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.

comment:2 by Erin Kelly, 13 years ago

Resolution: invalid
Status: newclosed

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.

comment:3 by Erin Kelly, 13 years ago

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.

comment:4 by dchud@…, 12 years ago

Easy pickings: unset
Resolution: invalid
Severity: Normal
Status: closedreopened
Type: Uncategorized
UI/UX: unset

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.

comment:5 by Aymeric Augustin, 11 years ago

Status: reopenednew

comment:6 by Aymeric Augustin, 11 years ago

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.

comment:7 by Aymeric Augustin, 11 years ago

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top