- attached cx_oracle.py.diff
Patch for cx_Oracle Unicode Removal
Support for Unicode mode was removed from version 5.1 of the cx_Oracle extension module on March 19, 2011.
http://cx-oracle.sourceforge.net/ http://cx-oracle.sourceforge.net/HISTORY.txt
The error below is returned when I use inspection and reflection in SQLAlchemy. I have attached a unified diff patch file that fixes a few version checks in sqlalchemy/dialects/oracle/cx_oracle.py. I am less familiar with the code than the author, so while you review the patch, please keep in mind that my primary focus was limited to the text encoding aspects of the code.
sqlalchemy.exc.DatabaseError: (DatabaseError) ORA-01460: unimplemented or unreasonable conversion requested
Thanks for making SQLAlchemy great!
Alex Eagar alexeagar@gmail.com
Comments (6)
-
Account Deleted -
repo owner - changed watchers to alexeagar@gmail.com
- changed milestone to 0.x.xx
- marked as major
Sorry, this is not a valid patch, and it's likely you have some other issue going on with your cx_Oracle installation, or are using some capability that has not yet been covered by SQLAlchemy's current featureset.
All of the flags you've disabled for 5.1 are supported in 5.1, and none have any connection to the ill-fated "UNICODE" mode, which is only remarked by the lack of the "UNICODE" indicator. cx_Oracle 5.1 has this present:
>>> import cx_Oracle >>> cx_Oracle.version '5.1' >>> cx_Oracle.UNICODE <type 'cx_Oracle.UNICODE'>
cx_oracle 5.1 also certainly has output type handlers present, this is the only the ability to use conn.outputtypehandler as documented at:
http://cx-oracle.sourceforge.net/html/connection.html#Connection.outputtypehandler
it also has distinct behavior for NVARCHAR:
http://cx-oracle.sourceforge.net/HISTORY.txt
Changes from 4.4.1 to 5.0 1) Added support for Python 3.0 with much help from Amaury Forgeot d'Arc. 2) Removed support for Python 2.3 and Oracle 8i. 3) Added support for full unicode mode in Python 2.x where all strings are passed in and returned as unicode (module must be built in this mode) rather than encoded strings **4) nchar and nvarchar columns now return unicode instead of encoded strings**
to use oracle with multibyte characters you need to have NLS_LANG set. We have dozens of tests of non-ASCII data and table schema creation/reflection on our buildbot which pass against SQLAlchemy 0.7 and the current version of cx_Oracle, 5.1.1:
http://jenkins.sqlalchemy.org/job/oracle-2.6/
to properly handle this issue, we need a fully reproducing test case, which includes the exact DDL to emit on Oracle that produces the schema you can't get to reflect. At the moment, usage of table/column names on oracle with multibyte characters has not been shown to be feasible, though its possible more recent versions of cx_oracle have improved upon this.
-
repo owner - changed status to wontfix
OK if you have more to add to this ticket, such as a test case, or suggestions for other changes I may have missed, please reopen! As it stands I like to close these if it appears like no further activity is warranted on our side.
-
Account Deleted Thanks for the feedback. There is an issue and the patch does resolve it for me, but I don't mind the ticket being closed until I have time to look into it further. Once I do finally get a chance to look in to it further, I will provide more detailed environment details and reproduction steps.
-
FYI, I faced the same ORA-01460 issue, and setting the NLS_LANG environment variable fixed it. So this issue is rightly closed.
-
repo owner - changed milestone to 1.x.xx
- Log in to comment
Unified Diff Patch File