Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Refs #12767 -- Modified the multi-db docs to remove the implication t…

…hat 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
  • Loading branch information...
commit f74b9aec10c26e605eb696122032d8220cb1806f 1 parent 1db672f
Russell Keith-Magee authored March 10, 2010

Showing 1 changed file with 29 additions and 29 deletions. Show diff stats Hide diff stats

  1. 58  docs/topics/db/multi-db.txt
58  docs/topics/db/multi-db.txt
@@ -74,7 +74,7 @@ Alternatively, if you want fine-grained control of synchronization,
74 74
 you can pipe all or part of the output of :djadmin:`sqlall` for a
75 75
 particular application directly into your database prompt, like this::
76 76
 
77  
-	$ ./manage.py sqlall sales | ./manage.py dbshell
  77
+    $ ./manage.py sqlall sales | ./manage.py dbshell
78 78
 
79 79
 Using other management commands
80 80
 -------------------------------
@@ -193,13 +193,13 @@ An example
193 193
     intentionally ignores some complex issues in order to
194 194
     demonstrate how routers are used.
195 195
 
196  
-    The approach of splitting ``contrib.auth`` onto a different
197  
-    database won't actually work on Postgres, Oracle, or MySQL with
198  
-    InnoDB tables. ForeignKeys to a remote database won't work due as
199  
-    they introduce referential integrity problems. If you're using
200  
-    SQLite or MySQL with MyISAM tables, there is no referential
201  
-    integrity checking, so you will be able to define cross-database
202  
-    foreign keys.
  196
+    This example won't work on Postgres, Oracle, or MySQL with InnoDB
  197
+    tables if any of the models in ``myapp`` contain foreign keys to
  198
+    models outside of the ``other`` database. ForeignKeys to a remote
  199
+    database introduce referential integrity problems that Django can't
  200
+    currently handle. However, if you're using SQLite or MySQL with MyISAM
  201
+    tables, there is no referential integrity checking, so you will be
  202
+    able to define cross-database foreign keys.
203 203
 
204 204
     The master/slave configuration described is also flawed -- it
205 205
     doesn't provide any solution for handling replication lag (i.e.,
@@ -207,38 +207,38 @@ An example
207 207
     write to propagate to the slaves). It also doesn't consider the
208 208
     interaction of transactions with the database utilization strategy.
209 209
 
210  
-So - what does this mean in practice? Say you want ``contrib.auth`` to
211  
-exist on the 'credentials' database, and you want all other models in a
212  
-master/slave relationship between the databases 'master', 'slave1' and
213  
-'slave2'. To implement this, you would need 2 routers::
  210
+So - what does this mean in practice? Say you want ``myapp`` to
  211
+exist on the ``other`` database, and you want all other models in a
  212
+master/slave relationship between the databases ``master``, ``slave1`` and
  213
+``slave2``. To implement this, you would need 2 routers::
214 214
 
215  
-    class AuthRouter(object):
  215
+    class MyAppRouter(object):
216 216
         """A router to control all database operations on models in
217  
-        the contrib.auth application"""
  217
+        the myapp application"""
218 218
 
219 219
         def db_for_read(self, model, **hints):
220  
-            "Point all operations on auth models to 'credentials'"
221  
-            if model._meta.app_label == 'auth':
222  
-                return 'credentials'
  220
+            "Point all operations on myapp models to 'other'"
  221
+            if model._meta.app_label == 'myapp':
  222
+                return 'other'
223 223
             return None
224 224
 
225 225
         def db_for_write(self, model, **hints):
226  
-            "Point all operations on auth models to 'credentials'"
227  
-            if model._meta.app_label == 'auth':
228  
-                return 'credentials'
  226
+            "Point all operations on myapp models to 'other'"
  227
+            if model._meta.app_label == 'myapp':
  228
+                return 'other'
229 229
             return None
230 230
 
231 231
         def allow_relation(self, obj1, obj2, **hints):
232  
-            "Allow any relation if a model in Auth is involved"
233  
-            if obj1._meta.app_label == 'auth' or obj2._meta.app_label == 'auth':
  232
+            "Allow any relation if a model in myapp is involved"
  233
+            if obj1._meta.app_label == 'myapp' or obj2._meta.app_label == 'myapp':
234 234
                 return True
235 235
             return None
236 236
 
237 237
         def allow_syncdb(self, db, model):
238  
-            "Make sure the auth app only appears on the 'credentials' db"
239  
-            if db == 'credentials':
240  
-                return model._meta.app_label == 'auth'
241  
-            elif model._meta.app_label == 'auth':
  238
+            "Make sure the myapp app only appears on the 'other' db"
  239
+            if db == 'other':
  240
+                return model._meta.app_label == 'myapp'
  241
+            elif model._meta.app_label == 'myapp':
242 242
                 return False
243 243
             return None
244 244
 
@@ -267,13 +267,13 @@ master/slave relationship between the databases 'master', 'slave1' and
267 267
 Then, in your settings file, add the following (substituting ``path.to.`` with
268 268
 the actual python path to the module where you define the routers)::
269 269
 
270  
-    DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.MasterSlaveRouter']
  270
+    DATABASE_ROUTERS = ['path.to.MyAppRouter', 'path.to.MasterSlaveRouter']
271 271
 
272 272
 The order in which routers are processed is significant. Routers will
273 273
 be queried in the order the are listed in the
274 274
 :setting:`DATABASE_ROUTERS` setting . In this example, the
275  
-``AuthRouter`` is processed before the ``MasterSlaveRouter``, and as a
276  
-result, decisions concerning the models in ``auth`` are processed
  275
+``MyAppRouter`` is processed before the ``MasterSlaveRouter``, and as a
  276
+result, decisions concerning the models in ``myapp`` are processed
277 277
 before any other decision is made. If the :setting:`DATABASE_ROUTERS`
278 278
 setting listed the two routers in the other order,
279 279
 ``MasterSlaveRouter.allow_syncdb()`` would be processed first. The

0 notes on commit f74b9ae

Please sign in to comment.
Something went wrong with that request. Please try again.