Refs #12767 -- Modified the multi-db docs to remove the implication that contrib.auth can be easily put on a separate database.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@12751 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee 2010-03-10 12:35:55 +00:00
parent 1db672f347
commit f74b9aec10
1 changed files with 29 additions and 29 deletions

View File

@ -193,13 +193,13 @@ An example
intentionally ignores some complex issues in order to intentionally ignores some complex issues in order to
demonstrate how routers are used. demonstrate how routers are used.
The approach of splitting ``contrib.auth`` onto a different This example won't work on Postgres, Oracle, or MySQL with InnoDB
database won't actually work on Postgres, Oracle, or MySQL with tables if any of the models in ``myapp`` contain foreign keys to
InnoDB tables. ForeignKeys to a remote database won't work due as models outside of the ``other`` database. ForeignKeys to a remote
they introduce referential integrity problems. If you're using database introduce referential integrity problems that Django can't
SQLite or MySQL with MyISAM tables, there is no referential currently handle. However, if you're using SQLite or MySQL with MyISAM
integrity checking, so you will be able to define cross-database tables, there is no referential integrity checking, so you will be
foreign keys. able to define cross-database foreign keys.
The master/slave configuration described is also flawed -- it The master/slave configuration described is also flawed -- it
doesn't provide any solution for handling replication lag (i.e., doesn't provide any solution for handling replication lag (i.e.,
@ -207,38 +207,38 @@ An example
write to propagate to the slaves). It also doesn't consider the write to propagate to the slaves). It also doesn't consider the
interaction of transactions with the database utilization strategy. interaction of transactions with the database utilization strategy.
So - what does this mean in practice? Say you want ``contrib.auth`` to So - what does this mean in practice? Say you want ``myapp`` to
exist on the 'credentials' database, and you want all other models in a exist on the ``other`` database, and you want all other models in a
master/slave relationship between the databases 'master', 'slave1' and master/slave relationship between the databases ``master``, ``slave1`` and
'slave2'. To implement this, you would need 2 routers:: ``slave2``. To implement this, you would need 2 routers::
class AuthRouter(object): class MyAppRouter(object):
"""A router to control all database operations on models in """A router to control all database operations on models in
the contrib.auth application""" the myapp application"""
def db_for_read(self, model, **hints): def db_for_read(self, model, **hints):
"Point all operations on auth models to 'credentials'" "Point all operations on myapp models to 'other'"
if model._meta.app_label == 'auth': if model._meta.app_label == 'myapp':
return 'credentials' return 'other'
return None return None
def db_for_write(self, model, **hints): def db_for_write(self, model, **hints):
"Point all operations on auth models to 'credentials'" "Point all operations on myapp models to 'other'"
if model._meta.app_label == 'auth': if model._meta.app_label == 'myapp':
return 'credentials' return 'other'
return None return None
def allow_relation(self, obj1, obj2, **hints): def allow_relation(self, obj1, obj2, **hints):
"Allow any relation if a model in Auth is involved" "Allow any relation if a model in myapp is involved"
if obj1._meta.app_label == 'auth' or obj2._meta.app_label == 'auth': if obj1._meta.app_label == 'myapp' or obj2._meta.app_label == 'myapp':
return True return True
return None return None
def allow_syncdb(self, db, model): def allow_syncdb(self, db, model):
"Make sure the auth app only appears on the 'credentials' db" "Make sure the myapp app only appears on the 'other' db"
if db == 'credentials': if db == 'other':
return model._meta.app_label == 'auth' return model._meta.app_label == 'myapp'
elif model._meta.app_label == 'auth': elif model._meta.app_label == 'myapp':
return False return False
return None return None
@ -267,13 +267,13 @@ master/slave relationship between the databases 'master', 'slave1' and
Then, in your settings file, add the following (substituting ``path.to.`` with Then, in your settings file, add the following (substituting ``path.to.`` with
the actual python path to the module where you define the routers):: the actual python path to the module where you define the routers)::
DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.MasterSlaveRouter'] DATABASE_ROUTERS = ['path.to.MyAppRouter', 'path.to.MasterSlaveRouter']
The order in which routers are processed is significant. Routers will The order in which routers are processed is significant. Routers will
be queried in the order the are listed in the be queried in the order the are listed in the
:setting:`DATABASE_ROUTERS` setting . In this example, the :setting:`DATABASE_ROUTERS` setting . In this example, the
``AuthRouter`` is processed before the ``MasterSlaveRouter``, and as a ``MyAppRouter`` is processed before the ``MasterSlaveRouter``, and as a
result, decisions concerning the models in ``auth`` are processed result, decisions concerning the models in ``myapp`` are processed
before any other decision is made. If the :setting:`DATABASE_ROUTERS` before any other decision is made. If the :setting:`DATABASE_ROUTERS`
setting listed the two routers in the other order, setting listed the two routers in the other order,
``MasterSlaveRouter.allow_syncdb()`` would be processed first. The ``MasterSlaveRouter.allow_syncdb()`` would be processed first. The