Django

Code

Ticket #4429 (closed: fixed)

Opened 1 year ago

Last modified 1 year ago

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

Reported by: Simon Willison Assigned to: adrian
Milestone: Component: Core framework
Version: SVN Keywords:
Cc: Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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

Change History

05/30/07 08:35:39 changed by mir@noris.de

  • needs_better_patch changed.
  • needs_tests changed.
  • needs_docs changed.

Does it help to set settings.TRANSACTIONS_MANAGED?

05/30/07 08:45:32 changed 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

05/30/07 21:39:01 changed by mtredinnick

  • 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.

06/01/07 09:37:02 changed by anonymous

  • has_patch set to 1.

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

06/01/07 09:37:25 changed by Simon Willison

Last anonymous comment was me

06/01/07 11:30:39 changed by simon

  • status changed from new to closed.
  • resolution set to fixed.

(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/Change #4429 (500 pages don't work unless you have configured Django database settings)




Change Properties
Action