#22620: "Multiple databases" chapter of docs says 'default':{} can start
DATABASES
setting; Django says no
--------------------------------------+------------------------------------
Reporter: moc@… | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.6
Severity: Normal | Resolution:
Keywords: multiple_databases | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Changes (by timgraham):
* has_patch: 0 => 1
Old description:
> 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_date__gt=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.
New description:
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_date__gt=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.
--
Comment:
For (1), I added a sentence about using DATABASE_ROUTERS to avoid any
queries to the default database if you want to run without one.
For (2), I added a similar sentence about using routers to avoid creating
tables where you don't want them, but avoided any specific recommendation
as I think it's best to let users figure out what tables they want and
where.
For (3), after further investigation, `migrate` does support the
`--database` flag and as far as I could tell the documentation is accurate
with respect to how it works.
Note that for apps with migrations `sqlall` is replaced by `sqlmigrate`.
Given the complexity of migrations, it seems like a bad idea to recommend
that as a "fine-grained" approach the way `sqlall` was, so I removed that
suggestion.
Feedback on the patch is welcome.
--
Ticket URL: <https://code.djangoproject.com/ticket/22620#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.bca85add02dd33adb643923169a7da04%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
