Skip to content

Commit

Permalink
[1.7.x] Fixed #22620 -- Emphasized role of DATABASE_ROTERS in multi-d…
Browse files Browse the repository at this point in the history
…b docs.

Thanks Mike O'Connor for the suggestions.

Backport of 5ecead9 from master
  • Loading branch information
timgraham committed Aug 26, 2014
1 parent 4f0916c commit 403cc55
Showing 1 changed file with 10 additions and 14 deletions.
24 changes: 10 additions & 14 deletions docs/topics/db/multi-db.txt
Original file line number Diff line number Diff line change
Expand Up @@ -47,8 +47,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. The following is an example ``settings.py`` snippet defining two
non-default databases, with the ``default`` entry intentionally left empty::
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::

DATABASES = {
'default': {},
Expand Down Expand Up @@ -87,12 +90,6 @@ particular database, you can define a :ref:`database
router<topics-db-multi-db-routing>` that implements a policy
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
-------------------------------

Expand Down Expand Up @@ -690,12 +687,11 @@ In addition, some objects are automatically created just after
database).

For common setups with multiple databases, it isn't useful to have these
objects in more than one database. Common setups include master / slave and
connecting to external databases. Therefore, it's recommended:

- either to run :djadmin:`migrate` only for the default database;
- or to write :ref:`database router<topics-db-multi-db-routing>` that allows
synchronizing these three models only to one database.
objects in more than one database. Common setups include primary/replica and
connecting to external databases. Therefore, it's recommended to write a
:ref:`database router<topics-db-multi-db-routing>` that allows synchronizing
these three models to only one database. Use the same approach for contrib
and third-party apps that don't need their tables in multiple databases.

.. warning::

Expand Down

2 comments on commit 403cc55

@michaelcoconnor
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tim thanks for the revisions. Look pretty good. About the migrate command, it's still the case that https://docs.djangoproject.com/en/1.6/ref/django-admin/#syncdb explicitly lists the --database option but https://docs.djangoproject.com/en/1.7/ref/django-admin/#s-migrate-app-label-migrationname doesn't. So if indeed it does support that option we need to add that to the latter docs for 1.7.

@timgraham
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documented `--database`` in 6aae07f, thanks.

Please sign in to comment.