apply "notes" to bind parameters or TypeEngine, to allow more accurate error reporting ?

[Former user]

Every now and then, I encounter warnings like

    .../sqlalchemy/engine/default.py:227:SAWarning: Unicode type received non-unicode bind param value ' '

Sometimes, the value aids in targetting the right column, but cases like these usually won't get you anywhere and debugging (or de-warning) gets a nightmare.

At first, I assumed it should be pretty trivial to have those warnings spit out the column (and table) name as well. I was able to locate the warning to be issued in types.py, line 322/323.

However, after some digging and testing, that seems kinda hard to do as there's probably no way to access the Column and Table instances that reference the type object without modifying or extending the type subclass to accept that information (and to modify the callers to pass that information). Also, inspecting stack frames might work, but due to the variety of ways to construct table mappings, that might grow into some bad hackery to get it work.

What are your thought about being able to achieve this handy improvement?

[Mike Bayer]

use the warnings filter (see "pydoc warnings") and turn those warnings into exceptions, or alternatively set the "assert_unicode=True" flag on your engine. The warning will result in a stack trace that will indicate the exact location where the non-unicode value is being assigned.

in fact when the assignment occurs, we're dealing with a bind parameter and at best, we could report the name given to the bind param, which is frequently meaningless or ambiguous. There's no "link" to the actual column at that point unless a complicated system of backtracking through the original expression object were constructed, which would be complex and unreliable in many situations.

There might be ways to have bind parameters be given "notes" about what column they correspond to at the point at which they are generated, if it is in fact a comparison or assignment to a column. This still seems like overkill to me but I'll leave it open as a possilibity.

[Former user]

Thanks, debugging using

import warnings
warnings.simplefilter('error')

is sufficient for me.

[Mike Bayer]

great, one less ticket....