Django ignoring my DATABASE_ENGINE setting -- sometimes

Question

I've got several sites, each with a distinct settings file -- and with distinct names. There's a floral theme to all the variant settings. We have to keep the sites separate.

C:\Proj-Carnation> echo %DJANGO_SETTINGS_MODULE%
path.to.settings_carnation_win32

We have many test procedures which don't use the built-in django-admin.py test command because they're large batch jobs that are started by the Django front-end, and use the Django ORM. We need to use the django.db.connection.creation.create_test_db() method to create a new test database.

We've been using this test procedure for quite a while. Currently, it's stopped working. We've made numerous code structure changes, upgraded to Django 1.1.1 and Python 2.6. All are possible culprits.

When I run Python I see this.

C:\Proj-Carnation> python
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from django.conf import settings
>>> settings.DATABASE_ENGINE
INSDIE django.db.__init__, settings.DATABASE_ENGINE=''
'sqlite3'
>>> import django.db
>>> django.db.connection
<django.db.backends.dummy.base.DatabaseWrapper object at 0x00EE88B0>

During the import of django.db, something the settings are clearly not set. I added a print statement (with misspelled "INSIDE") in django.db. The settings are not set.

Eventually, settings.DATABASE_ENGINE becomes 'sqlite3'. To an extend this "eventually" behavior is expected: the settings module uses a lazy loader technique.

The issue is this: The connection -- built from incomplete settings -- is the dummy database backend. Yet, the final settings show the engine to be 'sqlite3'.

In another project (the "Root" Project), there are no issues. Things work perfectly. The DB settings create the proper sqlite3 backend instance.

So, what's different? I'm stumped. It's the environment settings or the physical directory trees are the top potential issues.

In the non-working C:\Proj-Carnation, the PYTHONPATH is C:\Proj-Carnation;C:\Proj-Root;C:\This;C:\That.

In the working root project C:\Proj-Carnation, the PYTHONPATH is C:\Proj-Root;C:\This;C:\That.

Am I looking for something in the "Carnation" project that has concealed something in the root project? Sadly, the Carnation project only has a few files and they're in a package (local) which assures that they names distinct from the root project.

Is there some Django initialization in version 1.1.1 that's different? For instance, is there something in django.conf that's out of whack with Python 2.6 and Django 1.1.1?

Is there some relative import issue that I've overlooked?

Answer 1

Found it.

When your settings module is inside a package, the top-level __init__.py member of that package cannot import any Django material of any kind.

If the top-level __init__.py that contains your settings has a Django import, that Django import will (potentially) use the default settings before your settings are created.

And since some things in Django (like the database connection) are singletons, the thing that got created while reading your settings is the only one that can ever exist.

Do not put anything in the __init__.py in the package that contains settings modules.