#33331: Improve exception handling with `cursor.close()` after errors
-------------------------------------+-------------------------------------
Reporter: Daniel Hahler | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: 3.2
(models, ORM) |
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Daniel Hahler):
The main thing this is meant to fix is not raising errors from
`cursor.close()` in the first place.
The difference between "caused by" and "then triggered also" is only
relevant for when it should not get swallowed (based on if it is expected
because there was an error already).
What you currently get during a test run with a missing migration:
{{{
Traceback (most recent call last):
File "…/Vcs/django/django/db/backends/utils.py", line 89, in _execute
return self.cursor.execute(sql, params)
psycopg2.errors.UndefinedColumn: column foo.bar does not exist
LINE 1: ...
^
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "…/Vcs/django/django/db/models/sql/compiler.py", line 1361, in
execute_sql
cursor.execute(sql, params)
…
File "…/Vcs/django/django/db/backends/utils.py", line 89, in _execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: column foo.bar does not exist
LINE 1: ...
^
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "…/project/.venv/lib/python3.10/site-
packages/pytest_django/fixtures.py", line 122, in django_db_setup
db_cfg = setup_databases(
…
File "…/Vcs/django/django/db/models/sql/compiler.py", line 1364, in
execute_sql
cursor.close()
psycopg2.errors.InvalidCursorName: cursor
"_django_curs_140147764090688_sync_10" does not exist
}}}
`psycopg2.errors.InvalidCursorName` is expected to happen here, and
obfuscates/hides the real error (e.g. when it gets used for display in the
short test summary etc).
The (current) patch changes it to:
{{{
Traceback (most recent call last):
File "…/Vcs/django/django/db/backends/utils.py", line 89, in _execute
return self.cursor.execute(sql, params)
psycopg2.errors.UndefinedColumn: column foo.bar does not exist
LINE 1: ...
^
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "…/project/.venv/lib/python3.10/site-
packages/pytest_django/fixtures.py", line 122, in django_db_setup
db_cfg = setup_databases(
…
File "…/Vcs/django/django/db/backends/utils.py", line 89, in _execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: column foo.bar does not exist
LINE 1: ...
^
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33331#comment:8>
Django <https://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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.61ad0bde2429328a2a3199fc7082d9fa%40djangoproject.com.
