Opened 10 years ago
Last modified 10 years ago
#25020 new New feature
Provide/log related args (SQL query, params, proc) with database errors
| Reported by: | Daniel Hahler | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Database errors should provide the SQL query being used (the sql and maybe params separately), e.g. in case of a DataError.
DatabaseErrorWrapper might just log these as an error, in case the reason is for the exception message not getting too long - but it's probably easier/better to apply this to CursorWrapper.execute, CursorWrapper.executemany and CursorWrapper.callproc (via some specialized context manager, which could be passed in relevant args that should be logged or added to the exception in case of error)?
It is annoying to figure out where e.g. some varchar length restriction might come from, and the SQL/params would make it more obvious.
While you can log queries with the django.db logger, CursorDebugWrapper or directly in Postgres, the former (logging queries in general) is noisy (and therefore not useful / usually enabled by default) and logging them in your DB should be abstracted away by Django and might be even not possible, in case you cannot control the DB settings in this regard.
There's probably room for improvement here.