#598: run_sql reports errors wrong
-----------------------+-------------------------------
Reporter: jblayloc | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: MiscUtil | Version:
Resolution: | Keywords: warning exception
-----------------------+-------------------------------
Comment (by skaplun):
Replying to [comment:2 jblayloc]:
> That doesn't count as a syntax error? I'm *very* surprised by this. Do
you know why they do it that way?
Well, the query is well formed, it is respecting the syntax:
{{{
SELECT
select_expr [, select_expr ...]
[FROM table_references
[WHERE where_condition]
}}}
It just happen that the where_condition specifies a value that is not
compatible with the type of the column. This is more like a runtime error,
and for these cases they decided to normalize the value to the default of
the column. It's like a dynamic typecast in C++. Now this is indeed
masking some bug in the outer code, so it makes perfect sense for us,
Invenio developers, to catch as early as possible these issues.
> Yes, I figured some of this out yesterday evening after filing this
ticket. I was thinking about whether I should devote time to figuring out
how to make dbquery do the magic dance to get warnings instatiated as
exceptions. I'm tempted to say that mysql problems should always throw
exceptions, but that may be too extreme; I think your suggestion about
gating on CFG_DEVEL_SITE is a good one.
>
> So you say you've already figured out how to do this...? :)
Partially. Basically one have to do
{{{
import warnings
warnings.filterwarnings('error', module='SOMETHING')
}}}
at the beginning of dbquery.py
The only issue I wasn't yet able to solve yet is what to put at the place
of ''SOMETHING'' :-( (it should be a regexp that matches the "module", but
which module and how to write the perfect regexp yet is a mistery to me
:-)
<http://docs.python.org/library/warnings.html#warning-filter>
--
Ticket URL: <http://invenio-software.org/ticket/598#comment:3>
Invenio <http://invenio-software.org>
