Updated documentation to reflect current stage of migrate_schemas and…

… sync_schemas.

README.rst

@@ -160,15 +160,15 @@ created ``Client`` inside an app named ``customers``, your
 
     TENANT_MODEL = "customers.Client" # app.Model
 
-Now run ``sync_schemas``, this will sync your apps to the ``public``
-schema.
+Now run ``migrate_schemas`` (``sync_schemas`` if you're on Django 1.6 and older), 
+this will sync your apps to the ``public`` schema.
 
 ::
 
-    python manage.py sync_schemas --shared
+    python manage.py migrate_schemas --shared
 
 Create your tenants just like a normal django model. Calling ``save``
-will automatically create and sync the schema.
+will automatically create and sync/migrate the schema.
 
 .. code-block:: python
 

docs/use.rst

@@ -29,9 +29,9 @@ Now we can create our first real tenant.
                     name='Fonzy Tenant',
                     paid_until='2014-12-05',
                     on_trial=True)
-    tenant.save() # sync_schemas automatically called, your tenant is ready to be used!
-    
-Because you have the tenant middleware installed, any request made to ``tenant.my-domain.com`` will now automatically set your PostgreSQL's ``search_path`` to ``tenant1, public``, making shared apps available too. The tenant will be made available at ``request.tenant``. By the way, the current schema is also available at ``connection.schema_name``, which is useful, for example, if you want to hook to any of django's signals. 
+    tenant.save() # migrate_schemas automatically called, your tenant is ready to be used!
+
+Because you have the tenant middleware installed, any request made to ``tenant.my-domain.com`` will now automatically set your PostgreSQL's ``search_path`` to ``tenant1, public``, making shared apps available too. The tenant will be made available at ``request.tenant``. By the way, the current schema is also available at ``connection.schema_name``, which is useful, for example, if you want to hook to any of django's signals.
 
 Any call to the methods ``filter``, ``get``, ``save``, ``delete`` or any other function involving a database connection will now be done at the tenant's schema, so you shouldn't need to change anything at your views.
 
@@ -68,51 +68,47 @@ To run only a particular schema, there is an optional argument called ``--schema
 
     ./manage.py sync_schemas --schema=customer1
 
-sync_schemas
-~~~~~~~~~~~~
+migrate_schemas    
+~~~~~~~~~~~~~~~
 
-The command ``sync_schemas`` is the most important command on this app. The way it works is that it calls Django's ``syncdb`` in two different ways. First, it calls ``syncdb`` for the ``public`` schema, only syncing the shared apps. Then it runs ``syncdb`` for every tenant in the database, this time only syncing the tenant apps.
+If you're on Django 1.7 or newer, ``migrate_schemas`` is the most important command on this app. The way it works is that it calls Django's ``migrate`` in two different ways. First, it calls ``migrate`` for the ``public`` schema, only syncing the shared apps. Then it runs ``migrate`` for every tenant in the database, this time only syncing the tenant apps.
 
 .. warning::
 
-   You should never directly call ``syncdb``. We perform some magic in order to make ``syncdb`` only sync the appropriate apps.
-
-The options given to ``sync_schemas`` are passed to every ``syncdb``. So if you use South, you may find this handy
+   You should never directly call ``migrate``. We perform some magic in order to make ``migrate`` only migrate the appropriate apps.
 
 .. code-block:: bash
 
-    ./manage.py sync_schemas --migrate
+    ./manage.py migrate_schemas
 
-You can also use the option ``--tenant`` to only sync tenant apps or ``--shared`` to only sync shared apps.
+The options given to ``migrate_schemas`` are also passed to every ``migrate``. Hence you may find handy
 
 .. code-block:: bash
 
-    ./manage.py sync_schemas --shared # will only sync the public schema
+    ./manage.py migrate_schemas --list
 
-migrate_schemas    
-~~~~~~~~~~~~~~~
+sync_schemas
+~~~~~~~~~~~~
 
-We've also packed south's migrate command in a compatible way with this app. It will also respect the ``SHARED_APPS`` and ``TENANT_APPS`` settings, so if you're migrating the ``public`` schema it will only migrate ``SHARED_APPS``. If you're migrating tenants, it will only migrate ``TENANT_APPS``.
+If you're on Django 1.6 or older, we also packed ``sync_schemas``. It will also respect the ``SHARED_APPS`` and ``TENANT_APPS`` settings, so if you're syncing the ``public`` schema it will only sync ``SHARED_APPS``. If you're syncing tenants, it will only migrate ``TENANT_APPS``.
 
-.. code-block:: bash
+.. warning::
 
-    ./manage.py migrate_schemas
+   You should never directly call ``syncdb``. We perform some magic in order to make ``syncdb`` only sync the appropriate apps.
 
-The options given to ``migrate_schemas`` are also passed to every ``migrate``. Hence you may find handy
+The options given to ``sync_schemas`` are passed to every ``syncdb``. So if you use South, you may find this handy
 
 .. code-block:: bash
 
-    ./manage.py migrate_schemas --list
+    ./manage.py sync_schemas --migrate
 
-Or
+You can also use the option ``--tenant`` to only sync tenant apps or ``--shared`` to only sync shared apps.
 
 .. code-block:: bash
 
-    ./manage.py migrate_schemas myapp 0001_initial --fake
-
-in case you're just switching your ``myapp`` application to use South migrations.
+    ./manage.py sync_schemas --shared # will only sync the public schema
 
-tenant_command    
+tenant_command
 ~~~~~~~~~~~~~~
 
 To run any command on an individual schema, you can use the special ``tenant_command``, which creates a wrapper around your command so that it only runs on the schema you specify. For example