#12612 closed (fixed)
SQLite3 executemany() exception handling is too broad
Description ¶
In SQLiteCursorWrapper.executemany() (http://code.djangoproject.com/browser/django/trunk/django/db/backends/sqlite3/base.py#L191)
convert_query (line 199) is called, but if you have an extra (accidental) %s in your query the
replacement of '%s' by ? will raise an exception (TypeError: not enough arguments for format string) which is then
caught and ignored by except(IndexError,TypeError) at line 195.
None will be returned and whoever is calling executemany will be left wondering why nothing happened. This bug basically causes bad input to be ignored instead of raising an exception.
Change History (7)
comment:1 by , 15 years ago
| Summary: | SQLite3 executemany() method catches too much exceptions → SQLite3 executemany() exception handling is too broad |
|---|
comment:2 by , 15 years ago
| milestone: | → 1.2 |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:3 by , 15 years ago
| Has patch: | set |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
by , 15 years ago
| Attachment: | 12612_patch.diff added |
|---|
Removes error suppression from sqlite executemany parameter handling and adds tests.
comment:4 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:5 by , 15 years ago
(In [12837]) [1.1.X] Fixed #12612 -- Corrected handling of parameter formatting in SQLite backend so that executemany raises exceptions when bad parameter counts are provided. Thanks to Niels <niels@…> for the report, and Gabriel Hurley for the help narrowing down the problem.
Backport of r12836 from trunk.
This was introduced in @6218 as the solution to #4765. I agree with Niels that the solution in that patch (suppressing an error regarding a malformed query and returning None) is not the right direction.
I can't find any discussion of why that decision was made, and there are no tests for executemany() anywhere that I see.
I'm adding a patch which lets the error bubble up and adds tests to check for the behaviors noted in this ticket and #4896.