On Wednesday, January 9, 2013 12:38:28 AM UTC-7, Jani Tiainen wrote:
>
> Tested against latest master. Same behaviour.
>
> In Oracle backend base.py is following piece of code:
>
> # Check whether cx_Oracle was compiled with the WITH_UNICODE option.
> This will
> # also be True in Python 3.0.
> if int(Database.version.split('.', 1)[0]) >= 5 and not hasattr(Database,
> 'UNICODE'):
> convert_unicode = force_text
> else:
> convert_unicode = force_bytes
>
> Which was added in <https://github.com/django/django/commit/dcf3be7a62>
>
> Thing is that my cx_Oracle is version 5.1.2, it has cx_Oracle.UNICODE
> definition.
>
That sounds correct. The cx_Oracle.UNICODE type constant is present when
cx_Oracle is compiled *without* the WITH_UNICODE option (which no longer
exists in 5.1 anyway).
> And Django uses smart_str / force_bytes.
>
> If I remove that and use convert_unicode as force_text / force_unicode
> everything works as expected.
>
Strange, in 5.1 it shouldn't make any difference which is used, as long as
your NLS_LANG is getting set properly in the backend. What is your server
setup? It seems that sometimes that can get interfered with if you have
other services using Oracle in the same process. It shouldn't hurt
anything though for us to do an additional check for cx_Oracle 5.1+ and
always use force_text in that case.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/CIo27txyz84J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
