Merge pull request #2692 from fcurella/patch-5

#22667 replaced occurrences of master/slave terminology with leader/follower

3 files changed, 57 insertions, 57 deletions

diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index a5f9b3451c..502b77fbf7 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -222,29 +222,29 @@ won't appear in the models cache, but the model details can be used
 for routing purposes.
 
 For example, the following router would direct all cache read
-operations to ``cache_slave``, and all write operations to
-``cache_master``. The cache table will only be synchronized onto
-``cache_master``::
+operations to ``cache_follower``, and all write operations to
+``cache_leader``. The cache table will only be synchronized onto
+``cache_leader``::
 
     class CacheRouter(object):
         """A router to control all database cache operations"""
 
         def db_for_read(self, model, **hints):
-            "All cache read operations go to the slave"
+            "All cache read operations go to the follower"
             if model._meta.app_label in ('django_cache',):
-                return 'cache_slave'
+                return 'cache_follower'
             return None
 
         def db_for_write(self, model, **hints):
-            "All cache write operations go to master"
+            "All cache write operations go to leader"
             if model._meta.app_label in ('django_cache',):
-                return 'cache_master'
+                return 'cache_leader'
             return None
 
         def allow_migrate(self, db, model):
-            "Only install the cache model on master"
+            "Only install the cache model on leader"
             if model._meta.app_label in ('django_cache',):
-                return db == 'cache_master'
+                return db == 'cache_leader'
             return None
 
 If you don't specify routing directions for the database cache model,
diff --git a/docs/topics/db/multi-db.txt b/docs/topics/db/multi-db.txt
index b85198f372..caa3ece817 100644
--- a/docs/topics/db/multi-db.txt
+++ b/docs/topics/db/multi-db.txt
@@ -197,17 +197,17 @@ Using routers
 
 Database routers are installed using the :setting:`DATABASE_ROUTERS`
 setting. This setting defines a list of class names, each specifying a
-router that should be used by the master router
+router that should be used by the leader router
 (``django.db.router``).
 
-The master router is used by Django's database operations to allocate
+The leader router is used by Django's database operations to allocate
 database usage. Whenever a query needs to know which database to use,
-it calls the master router, providing a model and a hint (if
+it calls the leader router, providing a model and a hint (if
 available). Django then tries each router in turn until a database
 suggestion can be found. If no suggestion can be found, it tries the
 current ``_state.db`` of the hint instance. If a hint instance wasn't
 provided, or the instance doesn't currently have database state, the
-master router will allocate the ``default`` database.
+leader router will allocate the ``default`` database.
 
 An example
 ----------
@@ -225,16 +225,16 @@ An example
     introduce referential integrity problems that Django can't
     currently handle.
 
-    The master/slave configuration described is also flawed -- it
+    The leader/follower configuration described is also flawed -- it
     doesn't provide any solution for handling replication lag (i.e.,
     query inconsistencies introduced because of the time taken for a
-    write to propagate to the slaves). It also doesn't consider the
+    write to propagate to the followers). It also doesn't consider the
     interaction of transactions with the database utilization strategy.
 
 So - what does this mean in practice? Let's consider another sample
 configuration. This one will have several databases: one for the
-``auth`` application, and all other apps using a master/slave setup
-with two read slaves. Here are the settings specifying these
+``auth`` application, and all other apps using a leader/follower setup
+with two read followers. Here are the settings specifying these
 databases::
 
     DATABASES = {
@@ -244,20 +244,20 @@ databases::
             'USER': 'mysql_user',
             'PASSWORD': 'swordfish',
         },
-        'master': {
-            'NAME': 'master',
+        'leader': {
+            'NAME': 'leader',
             'ENGINE': 'django.db.backends.mysql',
             'USER': 'mysql_user',
             'PASSWORD': 'spam',
         },
-        'slave1': {
-            'NAME': 'slave1',
+        'follower1': {
+            'NAME': 'follower1',
             'ENGINE': 'django.db.backends.mysql',
             'USER': 'mysql_user',
             'PASSWORD': 'eggs',
         },
-        'slave2': {
-            'NAME': 'slave2',
+        'follower2': {
+            'NAME': 'follower2',
             'ENGINE': 'django.db.backends.mysql',
             'USER': 'mysql_user',
             'PASSWORD': 'bacon',
@@ -309,30 +309,30 @@ send queries for the ``auth`` app to ``auth_db``::
             return None
 
 And we also want a router that sends all other apps to the
-master/slave configuration, and randomly chooses a slave to read
+leader/follower configuration, and randomly chooses a follower to read
 from::
 
     import random
 
-    class MasterSlaveRouter(object):
+    class LeaderFollowerRouter(object):
         def db_for_read(self, model, **hints):
             """
-            Reads go to a randomly-chosen slave.
+            Reads go to a randomly-chosen follower.
             """
-            return random.choice(['slave1', 'slave2'])
+            return random.choice(['follower1', 'follower2'])
 
         def db_for_write(self, model, **hints):
             """
-            Writes always go to master.
+            Writes always go to leader.
             """
-            return 'master'
+            return 'leader'
 
         def allow_relation(self, obj1, obj2, **hints):
             """
             Relations between objects are allowed if both objects are
-            in the master/slave pool.
+            in the leader/follower pool.
             """
-            db_list = ('master', 'slave1', 'slave2')
+            db_list = ('leader', 'follower1', 'follower2')
             if obj1._state.db in db_list and obj2._state.db in db_list:
                 return True
             return None
@@ -347,17 +347,17 @@ Finally, in the settings file, we add the following (substituting
 ``path.to.`` with the actual python path to the module(s) where the
 routers are defined)::
 
-    DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.MasterSlaveRouter']
+    DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.LeaderFollowerRouter']
 
 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
+``AuthRouter`` is processed before the ``LeaderFollowerRouter``, and as a
 result, decisions concerning the models in ``auth`` are processed
 before any other decision is made. If the :setting:`DATABASE_ROUTERS`
 setting listed the two routers in the other order,
-``MasterSlaveRouter.allow_migrate()`` would be processed first. The
-catch-all nature of the MasterSlaveRouter implementation would mean
+``LeaderFollowerRouter.allow_migrate()`` would be processed first. The
+catch-all nature of the LeaderFollowerRouter implementation would mean
 that all models would be available on all databases.
 
 With this setup installed, lets run some Django code::
@@ -369,7 +369,7 @@ With this setup installed, lets run some Django code::
     >>> # This save will also be directed to 'auth_db'
     >>> fred.save()
 
-    >>> # These retrieval will be randomly allocated to a slave database
+    >>> # These retrieval will be randomly allocated to a follower database
     >>> dna = Person.objects.get(name='Douglas Adams')
 
     >>> # A new object has no database allocation when created
@@ -379,10 +379,10 @@ With this setup installed, lets run some Django code::
     >>> # the same database as the author object
     >>> mh.author = dna
 
-    >>> # This save will force the 'mh' instance onto the master database...
+    >>> # This save will force the 'mh' instance onto the leader database...
     >>> mh.save()
 
-    >>> # ... but if we re-retrieve the object, it will come back on a slave
+    >>> # ... but if we re-retrieve the object, it will come back on a follower
     >>> mh = Book.objects.get(title='Mostly Harmless')
 
 
@@ -690,7 +690,7 @@ In addition, some objects are automatically created just after
   database).
 
 For common setups with multiple databases, it isn't useful to have these
-objects in more than one database. Common setups include master / slave and
+objects in more than one database. Common setups include leader / follower and
 connecting to external databases. Therefore, it's recommended:
 
 - either to run :djadmin:`migrate` only for the default database;
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index 3439686210..de9c09b919 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -64,16 +64,16 @@ The following is a simple unit test using the request factory::
 Tests and multiple databases
 ============================
 
-.. _topics-testing-masterslave:
+.. _topics-testing-leaderfollower:
 
-Testing master/slave configurations
+Testing leader/follower configurations
 -----------------------------------
 
-If you're testing a multiple database configuration with master/slave
+If you're testing a multiple database configuration with leader/follower
 replication, this strategy of creating test databases poses a problem.
 When the test databases are created, there won't be any replication,
-and as a result, data created on the master won't be seen on the
-slave.
+and as a result, data created on the leader won't be seen on the
+follower.
 
 To compensate for this, Django allows you to define that a database is
 a *test mirror*. Consider the following (simplified) example database
@@ -83,34 +83,34 @@ configuration::
         'default': {
             'ENGINE': 'django.db.backends.mysql',
             'NAME': 'myproject',
-            'HOST': 'dbmaster',
+            'HOST': 'dbleader',
              # ... plus some other settings
         },
-        'slave': {
+        'follower': {
             'ENGINE': 'django.db.backends.mysql',
             'NAME': 'myproject',
-            'HOST': 'dbslave',
+            'HOST': 'dbfollower',
             'TEST_MIRROR': 'default'
             # ... plus some other settings
         }
     }
 
-In this setup, we have two database servers: ``dbmaster``, described
-by the database alias ``default``, and ``dbslave`` described by the
-alias ``slave``. As you might expect, ``dbslave`` has been configured
-by the database administrator as a read slave of ``dbmaster``, so in
-normal activity, any write to ``default`` will appear on ``slave``.
+In this setup, we have two database servers: ``dbleader``, described
+by the database alias ``default``, and ``dbfollower`` described by the
+alias ``follower``. As you might expect, ``dbfollower`` has been configured
+by the database administrator as a read follower of ``dbleader``, so in
+normal activity, any write to ``default`` will appear on ``follower``.
 
 If Django created two independent test databases, this would break any
-tests that expected replication to occur. However, the ``slave``
+tests that expected replication to occur. However, the ``follower``
 database has been configured as a test mirror (using the
 :setting:`TEST_MIRROR` setting), indicating that under testing,
-``slave`` should be treated as a mirror of ``default``.
+``follower`` should be treated as a mirror of ``default``.
 
-When the test environment is configured, a test version of ``slave``
-will *not* be created. Instead the connection to ``slave``
+When the test environment is configured, a test version of ``follower``
+will *not* be created. Instead the connection to ``follower``
 will be redirected to point at ``default``. As a result, writes to
-``default`` will appear on ``slave`` -- but because they are actually
+``default`` will appear on ``follower`` -- but because they are actually
 the same database, not because there is data replication between the
 two databases.