mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-11-04 13:39:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Fixed #22620 -- Emphasized role of DATABASE_ROTERS in multi-db docs.

Browse source 
Thanks Mike O'Connor for the suggestions.
This commit is contained in:
Tim Graham 2014-08-26 15:43:23 -04:00
parent 7b9537fb27
commit 5ecead9ab9
1 changed files with 9 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

22
docs/topics/db/multi-db.txt
View file

@ -45,8 +45,11 @@ 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 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 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 be defined, but the parameters dictionary can be left blank if it will not be
used. The following is an example ``settings.py`` snippet defining two used. You must setup :setting:`DATABASE_ROUTERS` for all of your apps' models,
non-default databases, with the ``default`` entry intentionally left empty:: including those in any contrib and third-party apps you are using, so that no
queries are routed to the default database in order to do this. The following
is an example ``settings.py`` snippet defining two non-default databases, with
the ``default`` entry intentionally left empty::
DATABASES = { DATABASES = {
'default': {}, 'default': {},
@ -85,12 +88,6 @@ particular database, you can define a :ref:`database
router<topics-db-multi-db-routing>` that implements a policy router<topics-db-multi-db-routing>` that implements a policy
constraining the availability of particular models. constraining the availability of particular models.
Alternatively, if you want fine-grained control of synchronization,
you can pipe all or part of the output of :djadmin:`sqlall` for a
particular application directly into your database prompt, like this::
$ ./manage.py sqlall sales | ./manage.py dbshell
Using other management commands Using other management commands
------------------------------- -------------------------------
@ -690,11 +687,10 @@ In addition, some objects are automatically created just after
For common setups with multiple databases, it isn't useful to have these For common setups with multiple databases, it isn't useful to have these
objects in more than one database. Common setups include primary/replica and objects in more than one database. Common setups include primary/replica and
connecting to external databases. Therefore, it's recommended: connecting to external databases. Therefore, it's recommended to write a
:ref:`database router<topics-db-multi-db-routing>` that allows synchronizing
- either to run :djadmin:`migrate` only for the default database; these three models to only one database. Use the same approach for contrib
- or to write :ref:`database router<topics-db-multi-db-routing>` that allows and third-party apps that don't need their tables in multiple databases.
synchronizing these three models only to one database.
.. warning:: .. warning::