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
|
@ -74,7 +74,7 @@ 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
|
||||
$ ./manage.py sqlall sales | ./manage.py dbshell
|
||||
|
||||
Using other management commands
|
||||
-------------------------------
|
||||
|
@ -193,13 +193,13 @@ An example
|
|||
intentionally ignores some complex issues in order to
|
||||
demonstrate how routers are used.
|
||||
|
||||
The approach of splitting ``contrib.auth`` onto a different
|
||||
database won't actually work on Postgres, Oracle, or MySQL with
|
||||
InnoDB tables. ForeignKeys to a remote database won't work due as
|
||||
they introduce referential integrity problems. If you're using
|
||||
SQLite or MySQL with MyISAM tables, there is no referential
|
||||
integrity checking, so you will be able to define cross-database
|
||||
foreign keys.
|
||||
This example won't work on Postgres, Oracle, or MySQL with InnoDB
|
||||
tables if any of the models in ``myapp`` contain foreign keys to
|
||||
models outside of the ``other`` database. ForeignKeys to a remote
|
||||
database introduce referential integrity problems that Django can't
|
||||
currently handle. However, if you're using SQLite or MySQL with MyISAM
|
||||
tables, there is no referential integrity checking, so you will be
|
||||
able to define cross-database foreign keys.
|
||||
|
||||
The master/slave configuration described is also flawed -- it
|
||||
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
|
||||
interaction of transactions with the database utilization strategy.
|
||||
|
||||
So - what does this mean in practice? Say you want ``contrib.auth`` to
|
||||
exist on the 'credentials' database, and you want all other models in a
|
||||
master/slave relationship between the databases 'master', 'slave1' and
|
||||
'slave2'. To implement this, you would need 2 routers::
|
||||
So - what does this mean in practice? Say you want ``myapp`` to
|
||||
exist on the ``other`` database, and you want all other models in a
|
||||
master/slave relationship between the databases ``master``, ``slave1`` and
|
||||
``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
|
||||
the contrib.auth application"""
|
||||
the myapp application"""
|
||||
|
||||
def db_for_read(self, model, **hints):
|
||||
"Point all operations on auth models to 'credentials'"
|
||||
if model._meta.app_label == 'auth':
|
||||
return 'credentials'
|
||||
"Point all operations on myapp models to 'other'"
|
||||
if model._meta.app_label == 'myapp':
|
||||
return 'other'
|
||||
return None
|
||||
|
||||
def db_for_write(self, model, **hints):
|
||||
"Point all operations on auth models to 'credentials'"
|
||||
if model._meta.app_label == 'auth':
|
||||
return 'credentials'
|
||||
"Point all operations on myapp models to 'other'"
|
||||
if model._meta.app_label == 'myapp':
|
||||
return 'other'
|
||||
return None
|
||||
|
||||
def allow_relation(self, obj1, obj2, **hints):
|
||||
"Allow any relation if a model in Auth is involved"
|
||||
if obj1._meta.app_label == 'auth' or obj2._meta.app_label == 'auth':
|
||||
"Allow any relation if a model in myapp is involved"
|
||||
if obj1._meta.app_label == 'myapp' or obj2._meta.app_label == 'myapp':
|
||||
return True
|
||||
return None
|
||||
|
||||
def allow_syncdb(self, db, model):
|
||||
"Make sure the auth app only appears on the 'credentials' db"
|
||||
if db == 'credentials':
|
||||
return model._meta.app_label == 'auth'
|
||||
elif model._meta.app_label == 'auth':
|
||||
"Make sure the myapp app only appears on the 'other' db"
|
||||
if db == 'other':
|
||||
return model._meta.app_label == 'myapp'
|
||||
elif model._meta.app_label == 'myapp':
|
||||
return False
|
||||
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
|
||||
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
|
||||
be queried in the order the are listed in the
|
||||
:setting:`DATABASE_ROUTERS` setting . In this example, the
|
||||
``AuthRouter`` is processed before the ``MasterSlaveRouter``, and as a
|
||||
result, decisions concerning the models in ``auth`` are processed
|
||||
``MyAppRouter`` is processed before the ``MasterSlaveRouter``, and as a
|
||||
result, decisions concerning the models in ``myapp`` are processed
|
||||
before any other decision is made. If the :setting:`DATABASE_ROUTERS`
|
||||
setting listed the two routers in the other order,
|
||||
``MasterSlaveRouter.allow_syncdb()`` would be processed first. The
|
||||
|
|
Loading…
Reference in New Issue