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:
parent
1db672f347
commit
f74b9aec10
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue