Opened 12 years ago

Closed 12 years ago

#11809 closed (wontfix)

Unable to test a non-db dependent django app without db configuration

Reported by: Prabhu Subramanian <prabhu.subramanian@…> Owned by: nobody
Component: Testing framework Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


We are able to write django applications that do not require database configurations. But when we test them using django test framework, the framework expects database configurations. Otherwise we get the below error.

raise ImproperlyConfigured, "You haven't set the DATABASE_ENGINE setting yet."
django.core.exceptions.ImproperlyConfigured: You haven't set the DATABASE_ENGINE setting yet.

A workaround is to specify sqlite3 and let the test framework create in-memory database. But I don't think this is a good solution.

Change History (4)

comment:1 Changed 12 years ago by Karen Tracey

Note you have said what you don't like without proposing what you would like instead. Some special setting to tell the test runner no database is needed? The test runner to figure out for itself if a database is needed? I don't see how the former is any better than just setting DATABASE_ENGINE to sqlite3. The latter strikes me as more trouble than it is worth for the small fraction (I'm guessing) of users who are running no-database Django apps. But I haven't given it a great deal of thought, particularly since you haven't actually said what it is you are proposing so perhaps you have something completely different in mind.

comment:2 Changed 12 years ago by Prabhu Subramanian <prabhu.subramanian@…>

if no DATABASE_ENGINE is given, why cant the test runner skip creating/deleting test database? No special value is required. This would satisfy the genuine cases where the app really doesn't require databases.

For the bad case, where a developer has left out DATABASE_ENGINE parameter, but is doing something with models that require db access, then the database accessing code is responsible for throwing these Exceptions.

I haven't cared to look at the code. Perhaps a patch can help?

comment:3 Changed 12 years ago by Prabhu Subramanian <prabhu.subramanian@…>

And IMHO from a framework perspective, this should be a valid requirement. There might be only few people using django for non-db apps right now. It is only a matter of some guy writing a blog post explaining how cool django is for non-db apps and the article getting picked up by slashdot and reddit. Then you will see several thousand doing it :)

comment:4 Changed 12 years ago by Russell Keith-Magee

Resolution: wontfix
Status: newclosed

I'm going to mark this wontfix - at least for now.

Like it or not, Django is a framework for building database-backed web sites. There may well be use cases for various parts of Django without using a database, but many parts of Django's internals rely on the notional existence of a database connection.

When the the deprecation of pre-multi-db settings has been completed, this will be a lot easier to implement - because the single database will become a list of databases, a list of 0 databases becomes a valid option. However, for the moment, we need to rely on the existence of a single database connection.

A workaround that hasn't been mentioned is writing your own test runner; subclassing the django test runner, and removing/nulling out the create database checks.

Note: See TracTickets for help on using tickets.
Back to Top