"Multiple databases" chapter of docs says 'default':{} can start DATABASES setting; Django says no

[moc@…]

Hi all. I refer to ​https://docs.djangoproject.com/en/1.5/topics/db/multi-db/ and I am using 1.5 but the later docs are the same. I quote from the docs:

"If the concept of a default database doesn’t make sense in the context of your project, you need to be careful to always specify the database that you want to use. Django requires that a default database entry be defined, but the parameters dictionary can be left blank if it will not be used."

So I did that and got the following:

"Internal Server Error: /admin/
Traceback (most recent call last):

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/core/handlers/base.py", line 115, in get_response

response = callback(request, *callback_args, callback_kwargs)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/admin/sites.py", line 219, in wrapper

return self.admin_view(view, cacheable)(*args, kwargs)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/utils/decorators.py", line 91, in _wrapped_view

response = view_func(request, *args, kwargs)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/views/decorators/cache.py", line 89, in _wrapped_view_func

response = view_func(request, *args, kwargs)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/admin/sites.py", line 196, in inner

if not self.has_permission(request):

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/admin/sites.py", line 149, in has_permission

return request.user.is_active and request.user.is_staff

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/utils/functional.py", line 204, in inner

self._setup()

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/utils/functional.py", line 270, in _setup

self._wrapped = self._setupfunc()

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/auth/middleware.py", line 18, in <lambda>

request.user = SimpleLazyObject(lambda: get_user(request))

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/auth/middleware.py", line 10, in get_user

request._cached_user = auth.get_user(request)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/auth/init.py", line 136, in get_user

user_id = request.session[SESSION_KEY]

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/sessions/backends/base.py", line 44, in getitem

return self._session[key]

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/sessions/backends/base.py", line 167, in _get_session

self._session_cache = self.load()

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/sessions/backends/db.py", line 18, in load

expire_dategt=timezone.now()

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/manager.py", line 143, in get

return self.get_query_set().get(*args, kwargs)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/query.py", line 398, in get

num = len(clone)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/query.py", line 106, in len

self._result_cache = list(self.iterator())

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/query.py", line 317, in iterator

for row in compiler.results_iter():

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/sql/compiler.py", line 775, in results_iter

for rows in self.execute_sql(MULTI):

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/sql/compiler.py", line 830, in execute_sql

sql, params = self.as_sql()

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/sql/compiler.py", line 74, in as_sql

out_cols = self.get_columns(with_col_aliases)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/sql/compiler.py", line 212, in get_columns

col_aliases)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/sql/compiler.py", line 299, in get_default_columns

r = '%s.%s' % (qn(alias), qn2(field.column))

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/models/sql/compiler.py", line 52, in quote_name_unless_alias

r = self.connection.ops.quote_name(name)

File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/db/backends/dummy/base.py", line 15, in complain

raise ImproperlyConfigured("settings.DATABASES is improperly configured. "

ImproperlyConfigured: settings.DATABASES is improperly configured. Please supply the ENGINE value. Check settings documentation for more details."

I include the traceback just to show that nothing originated in code of mine. Now previously, and now in fact (I switched back), I have my project up and running fine with two databases and with the 'default' key value being the dictionary of parameters for the first database. So I have reason to suggest that perhaps the docs are wrong concerning the possibility of starting with 'default':{}. Maybe it's a legacy thing that is no longer viable.

If I could move on to another item on that very page... this is nit-picky I know but some of us are like that. Sorry. I'm talking about some lines at the very end of the page:

"For common setups with multiple databases, it isn’t useful to have these objects in more than one database... Therefore, it’s recommended:

either to run syncdb only for the default database;
..."

After reading it several times I concluded that by "these objects" was meant only the objects of the preceding paragraph, which include only Site, ContentType and Permission objects. However, I have just experimented and found that dropping from my second database all of the tables associated with ALL of the objects mentioned in the subsection "Behavior of contrib apps" causes no harm.

I therefore suggest that the language there could be clarified. Also, the mentioned option "either to run syncdb only for the default database" could use, say a parenthetic reference to the "$ ./manage.py sqlall sales | ./manage.py dbshell" approach... if that's what you have in mind for syncing the other database.