mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-31 09:41:08 +00:00
Code Issues 32 Releases Wiki Activity

Edited multi-db topic guide for grammar and clarity.

Browse Source
This commit is contained in:
Liz Lemon
2016-08-02 19:55:57 -04:00
committed by Tim Graham
parent e139ef5741
commit ea65c7cb48
1 changed files with 24 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/topics/db/multi-db.txt
View File

@@ -45,11 +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
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. You must setup :setting:`DATABASE_ROUTERS` for all of your apps' models,
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::
used. To do this, you must set up :setting:`DATABASE_ROUTERS` for all of your
apps' models, including those in any contrib and third-party apps you're using,
so that no queries are routed to the default database. The following is an
example ``settings.py`` snippet defining two non-default databases, with the
``default`` entry intentionally left empty::
DATABASES = {
'default': {},
@@ -78,7 +78,7 @@ The :djadmin:`migrate` management command operates on one database at a
time. By default, it operates on the ``default`` database, but by
providing the :option:`--database <migrate --database>` option, you can tell it
to synchronize a different database. So, to synchronize all models onto
all databases in our example, you would need to call::
all databases in the first example above, you would need to call::
$ ./manage.py migrate
$ ./manage.py migrate --database=users
@@ -88,6 +88,13 @@ particular database, you can define a :ref:`database
router<topics-db-multi-db-routing>` that implements a policy
constraining the availability of particular models.
If, as in the second example above, you've left the ``default`` database empty,
you must provide a database name each time you run :djadmin:`migrate`. Omitting
the database name would raise an error. For the second example::
$ ./manage.py migrate --database=users
$ ./manage.py migrate --database=customers
Using other management commands
-------------------------------
@@ -359,8 +366,8 @@ routers are defined)::
DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.PrimaryReplicaRouter']
The order in which routers are processed is significant. Routers will
be queried in the order the are listed in the
:setting:`DATABASE_ROUTERS` setting . In this example, the
be queried in the order they are listed in the
:setting:`DATABASE_ROUTERS` setting. In this example, the
``AuthRouter`` is processed before the ``PrimaryReplicaRouter``, and as a
result, decisions concerning the models in ``auth`` are processed
before any other decision is made. If the :setting:`DATABASE_ROUTERS`
@@ -394,6 +401,13 @@ With this setup installed, lets run some Django code::
>>> # ... but if we re-retrieve the object, it will come back on a replica
>>> mh = Book.objects.get(title='Mostly Harmless')
This example defined a router to handle interaction with models from the
``auth`` app, and other routers to handle interaction with all other apps. If
you left your ``default`` database empty and don't want to define a catch-all
database router to handle all apps not otherwise specified, your routers must
handle the names of all apps in :setting:`INSTALLED_APPS` before you migrate.
See :ref:`contrib_app_multiple_databases` for information about contrib apps
that must be together in one database.
Manually selecting a database
=============================
@@ -586,7 +600,8 @@ where all objects of a given type are stored on a specific database
usage of multiple databases is more complex, your ``ModelAdmin`` will
need to reflect that strategy.
Inlines can be handled in a similar fashion. They require three customized methods::
:class:`~django.contrib.admin.InlineModelAdmin` objects can be handled in a
similar fashion. They require three customized methods::
class MultiDBTabularInline(admin.TabularInline):
using = 'other'