From f74b9aec10c26e605eb696122032d8220cb1806f Mon Sep 17 00:00:00 2001 From: Russell Keith-Magee Date: Wed, 10 Mar 2010 12:35:55 +0000 Subject: [PATCH] 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 --- docs/topics/db/multi-db.txt | 58 ++++++++++++++++++------------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/docs/topics/db/multi-db.txt b/docs/topics/db/multi-db.txt index 0b8e90832b7..72b51165044 100644 --- a/docs/topics/db/multi-db.txt +++ b/docs/topics/db/multi-db.txt @@ -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