#5171: postgresql_psycopg2 backend registers psycopg2's UNICODE extension, which
can cause interference if Django is not the only component using psycopg2
------------------------------------------------+---------------------------
Reporter: Chris Wagner <[EMAIL PROTECTED]> | Owner: adrian
Status: new | Component:
Database wrapper
Version: SVN | Resolution:
Keywords: | Stage: Design
decision needed
Has_patch: 0 | Needs_docs: 0
Needs_tests: 0 | Needs_better_patch: 0
------------------------------------------------+---------------------------
Comment (by Chris Wagner <[EMAIL PROTECTED]>):
I'm sorry, but if it's between SQLAlchemy and Django, then Django is the
broken component. Like I said, I think it comes down to a weakness (i.e.,
bug) in psycopg2, but if we set aside that fact, then Django is to blame,
because Django is the component that is doing the ''assuming''.
You see, by setting the psycopg2 "UNICODE mode" (i.e., calling
{{{psycopg2.extensions.register_type(psycopg2.extensions.UNICODE)}}}),
Django is ''changing the environment''. As far as I know, SQLAlchemy is
not changing the environment. Therefore, SQLAlchemy will not be dirtying
the waters for other components (other libraries, extensions,
applications, etc.).
BTW, SQLAlchemy actually ''does'' check the result that is returned from a
database backend. I've looked at the code, and I've seen that it actually
has a check similar to this, when retrieving a result value from the
database:
{{{
if not isinstance(result_value, unicode):
return result_value.decode(dialect.encoding)
}}}
The {{{UnicodeDecodeError}}} is actually raised upon a call to psycopg2's
{{{cursor.fetchall()}}}.
I think I may have caused a little confusion in my original post. I think
you may be under the impression that SQLAlchemy should be setting the
connection encoding. Perhaps it could, but SQLAlchemy is being the more
conservative player, as it is not making changes that affect things
outside its scope (AFAIK). I would agree, however, that SQLAlchemy might
be able to make itself a bit more resilient to psycopg2's settings.
Whether or not this bug gets fixed is not incredibly important to me.
Like I said before, I'm more concerned about others stumbling across the
same issue, which is very difficult to diagnose. I am trying to migrate
away from Django (or at least the database-enabled portions). I'd just
like to do my part in the free software community.
--
Ticket URL: <http://code.djangoproject.com/ticket/5171#comment:5>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
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-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
