#16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a
later DatabaseError that masks the original one
-------------------------------------+-------------------------------------
Reporter: aaron | Owner: nobody
Type: Bug | Status: new
Milestone: | Component: Core (Other)
Version: 1.3 | Severity: Normal
Resolution: | Keywords: ExceptionReporter
Triage Stage: Accepted | DatabaseError current transaction
Needs documentation: 0 | aborted error queryset
Patch needs improvement: 0 | Has patch: 0
UI/UX: 0 | Needs tests: 0
| Easy pickings: 0
-------------------------------------+-------------------------------------
Comment (by aaron):
What about adding a method to {{{QuerySet}}}? Something like
{{{QuerySet.safe_repr()}}}, which acts the way I described above, and then
we can do an {{{isinstance}}} check and call that method instead of
pprint. That way if this issue comes up in other places there will be a
clear way to fix it, and anyone modifying {{{QuerySet}}} will be aware
that this use case exists.
Monkey patching always has the issue that it's hard to notice when
changing the original code.
For the DB don't-do-anything mode idea, what would the behaviour be?
Return empty results, or raise an exception? Raising a special exception
would be nice, perhaps, because the template code could catch it and
display a clear message.
--
Ticket URL: <https://code.djangoproject.com/ticket/16374#comment:4>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
