Re: [Sqlalchemy-tickets] [sqlalchemy] #2871: UnicodeDecodeError is thrown instead of StatementError if the statement with non-ASCII symbols lacks parameter bind value

[sqlalchemy <mi...@zz...>]

#2871: UnicodeDecodeError is thrown instead of StatementError if the statement
with non-ASCII symbols lacks parameter bind value
-----------------------------------+----------------------------------
      Reporter:  pupssman          |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:  0.8.xx
     Component:  engine            |   Severity:  minor - half an hour
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * status_field:  awaiting triage => completed/closed


Comment:

 the code is unclear in this regard in that the variable name `statement`
 within `base.py` is used to represent SQL statements in at least three
 forms; as a string, as a `Compiled` object, and as a `ClauseElement`.  In
 this case, the statement enters the method as a `Compiled` construct, so
 in order for it to be part of the `StatementException` object's message,
 we need to call its `__str__()` or `__unicode__()` method.  After we get
 an `ExecutionContext`, the same name `statement` is re-assigned to the
 stringified SQL statement, so is then handled as a string.   So the name
 `statement` throughout `engine/base.py` might be better if it were renamed
 to clarify its type.

 thanks for the test!

 rad85ab12d62e65b0310c778057551bcdd460f0d9 0.8

 rf112dc1d533033f19186eb65227aba1660d03102 0.9

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2871#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python