Opened 15 years ago
Closed 15 years ago
#10566 closed (fixed)
Support cx_Oracle compiled with WITH_UNICODE
| Reported by: | Erin Kelly | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Keywords: | oracle unicode | |
| Cc: | Matt Boersma | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
If cx_Oracle 5.0.1+ is compiled with the WITH_UNICODE option, then it expects unicode inputs and rejects str inputs. Currently the oracle backend only passes encoded strings and so won't work with this setup.
This is something we'll need to address eventually as Django moves to Python 3.0 support, but another use case may be when running Django together with other software in the same Apache instance, resulting in NLS_LANG confusion, as documented in this thread: http://groups.google.com/group/django-users/browse_thread/thread/fb812a572168bfc8?hl=en
Attachments (2)
Change History (5)
comment:1 by , 15 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
by , 15 years ago
| Attachment: | 10566.diff added |
|---|
comment:2 by , 15 years ago
| Has patch: | set |
|---|
This patch seems to work, but I haven't run the full test suite or the gis tests yet.
by , 15 years ago
| Attachment: | 10566-2.diff added |
|---|
This revised patch avoids a bug where calling setinputsizes with an NCLOB argument results in an error under cx_Oracle 5.0.1 with unicode.
comment:3 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This should be fairly routine, since we already do a bunch of conversions more or less in one place and we can hook in there. The only potential challenge is knowing when to do this. Is it detectable from querying something in
cx_oracle? Or do we need to add aDATABASE_OPTIONSkey for it so that the user can tell us?