Code

Opened 7 years ago

Closed 7 years ago

#4429 closed (fixed)

500 pages don't work unless you have configured Django database settings

Reported by: Simon Willison Owned by: adrian
Component: Core (Other) Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

If you aren't using Django's ORM, 500 server error pages fail to render. Here's the output from the Apache error log:

[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/lib/python2.4/site-packages/mod_python/importer.py", line 1128, in _execute_target\n    result = object(arg)
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/local/django/django_src/django/core/handlers/modpython.py", line 177, in handler\n    return ModPythonHandler()(req)
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/local/django/django_src/django/core/handlers/modpython.py", line 150, in __call__\n    response = self.get_response(request)
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py", line 115, in get_response\n    receivers = dispatcher.send(signal=signals.got_request_exception)
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/lib/python2.4/site-packages/django/dispatch/dispatcher.py", line 358, in send\n    sender=sender,
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/lib/python2.4/site-packages/django/dispatch/robustapply.py", line 47, in robustApply\n    return receiver(*arguments, **named)
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/local/django/django_src/django/db/__init__.py", line 48, in _rollback_on_exception\n    transaction.rollback_unless_managed()
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/local/django/django_src/django/db/transaction.py", line 145, in rollback_unless_managed\n    connection._rollback()
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3]   File "/usr/local/django/django_src/django/db/backends/dummy/base.py", line 13, in complain\n    raise ImproperlyConfigured, "You haven't set the DATABASE_ENGINE setting yet."
[Wed May 30 12:14:13 2007] [error] [client 192.168.1.3] ImproperlyConfigured: You haven't set the DATABASE_ENGINE setting yet.

Basically, the DB engine is hooked in through signals.got_request_exception and tries to roll back the connection.

Attachments (0)

Change History (6)

comment:1 Changed 7 years ago by mir@…

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Does it help to set settings.TRANSACTIONS_MANAGED?

comment:2 Changed 7 years ago by Simon Willison

I've fixed this locally by making the Dummy connection._rollback() a no-op, but I'm not sure if this is the best way to handle the problem in the long term:

Index: django/db/backends/dummy/base.py
===================================================================
--- django/db/backends/dummy/base.py    (revision 5379)
+++ django/db/backends/dummy/base.py    (working copy)
@@ -12,6 +12,9 @@
 def complain(*args, **kwargs):
     raise ImproperlyConfigured, "You haven't set the DATABASE_ENGINE setting yet."
 
+def ignore(*args, **kwargs):
+    pass
+
 class DatabaseError(Exception):
     pass
 
@@ -21,7 +24,7 @@
 class DatabaseWrapper:
     cursor = complain
     _commit = complain
-    _rollback = complain
+    _rollback = ignore
 
     def __init__(self, **kwargs):
         pass

comment:3 Changed 7 years ago by mtredinnick

  • Triage Stage changed from Unreviewed to Accepted

There was another ticket opened about the dummy backend recently with similar issues. I think this is the right way to handle it: by specifying dummy as the backend, you are saying you don't want the database to interfere. So having operations default to "always succeeded" feel like the right thing. Dummy isn't a very good choice for checking that you don't use the database at all, so having accesses fail dramatically feels wong.

comment:4 Changed 7 years ago by anonymous

  • Has patch set

In that case _commit should be assigned to "ignore" as well. Any reason for me not to just check this in?

comment:5 Changed 7 years ago by Simon Willison

Last anonymous comment was me

comment:6 Changed 7 years ago by simon

  • Resolution set to fixed
  • Status changed from new to closed

(In [5410]) rollback on dummy database now has no effect (previously raised an error). This means that custom 500 error pages (and e-mailed exceptions) now work even if a database has not been configured. Fixes #4429.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.