Rename pre_ and post_syncdb to *_migrate, with aliases from old names

3 files changed, 65 insertions, 34 deletions

diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
index 48f781310c..f6480cae3a 100644
--- a/docs/ref/contrib/sites.txt
+++ b/docs/ref/contrib/sites.txt
@@ -267,7 +267,7 @@ To enable the sites framework, follow these steps:
 3. Run :djadmin:`migrate`.
 
 ``django.contrib.sites`` registers a
-:data:`~django.db.models.signals.post_syncdb` signal handler which creates a
+:data:`~django.db.models.signals.post_migrate` signal handler which creates a
 default site named ``example.com`` with the domain ``example.com``. This site
 will also be created after Django creates the test database. To set the
 correct name and domain for your project, you can use an :doc:`initial data
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index d4f261cadb..b988371aa7 100644
--- a/docs/ref/signals.txt
+++ b/docs/ref/signals.txt
@@ -360,40 +360,36 @@ Management signals
 
 Signals sent by :doc:`django-admin </ref/django-admin>`.
 
-pre_syncdb
-----------
+pre_migrate
+-----------
 
-.. data:: django.db.models.signals.pre_syncdb
+.. data:: django.db.models.signals.pre_migrate
    :module:
 
-Sent by the :djadmin:`syncdb` command before it starts to install an
+Sent by the :djadmin:`migrate` command before it starts to install an
 application.
 
 Any handlers that listen to this signal need to be written in a particular
 place: a ``management`` module in one of your :setting:`INSTALLED_APPS`. If
 handlers are registered anywhere else they may not be loaded by
-:djadmin:`syncdb`.
+:djadmin:`migrate`.
 
 Arguments sent with this signal:
 
 ``sender``
-    The ``models`` module that was just installed. That is, if
-    :djadmin:`syncdb` just installed an app called ``"foo.bar.myapp"``,
-    ``sender`` will be the ``foo.bar.myapp.models`` module.
+    The ``models`` module of the app about to be migrated/synced.
+    For example, if :djadmin:`migrate` is about to install
+    an app called ``"foo.bar.myapp"``, ``sender`` will be the
+    ``foo.bar.myapp.models`` module.
 
 ``app``
     Same as ``sender``.
 
-``create_models``
-    A list of the model classes from any app which :djadmin:`syncdb` plans to
-    create.
-
-
 ``verbosity``
     Indicates how much information manage.py is printing on screen. See
     the :djadminopt:`--verbosity` flag for details.
 
-    Functions which listen for :data:`pre_syncdb` should adjust what they
+    Functions which listen for :data:`pre_migrate` should adjust what they
     output to the screen based on the value of this argument.
 
 ``interactive``
@@ -407,42 +403,57 @@ Arguments sent with this signal:
 ``db``
     The alias of database on which a command will operate.
 
-post_syncdb
------------
 
-.. data:: django.db.models.signals.post_syncdb
+pre_syncdb
+----------
+
+.. data:: django.db.models.signals.pre_syncdb
    :module:
 
-Sent by the :djadmin:`syncdb` command after it installs an application, and the
+.. deprecated:: 1.7
+
+    This signal has been renamed to :data:`~django.db.models.signals.pre_migrate`.
+
+Alias of :data:`django.db.models.signals.pre_migrate`. As long as this alias
+is present, for backwards-compatability this signal has an extra argument it sends:
+
+``create_models``
+    A list of the model classes from any app which :djadmin:`migrate` is
+    going to create, **only if the app has no migrations**.
+
+
+post_migrate
+------------
+
+.. data:: django.db.models.signals.post_migrate
+   :module:
+
+Sent by the :djadmin:`migrate` command after it installs an application, and the
 :djadmin:`flush` command.
 
 Any handlers that listen to this signal need to be written in a particular
 place: a ``management`` module in one of your :setting:`INSTALLED_APPS`. If
 handlers are registered anywhere else they may not be loaded by
-:djadmin:`syncdb`. It is important that handlers of this signal perform
+:djadmin:`migrate`. It is important that handlers of this signal perform
 idempotent changes (e.g. no database alterations) as this may cause the
 :djadmin:`flush` management command to fail if it also ran during the
-:djadmin:`syncdb` command.
+:djadmin:`migrate` command.
 
 Arguments sent with this signal:
 
 ``sender``
     The ``models`` module that was just installed. That is, if
-    :djadmin:`syncdb` just installed an app called ``"foo.bar.myapp"``,
+    :djadmin:`migrate` just installed an app called ``"foo.bar.myapp"``,
     ``sender`` will be the ``foo.bar.myapp.models`` module.
 
 ``app``
     Same as ``sender``.
 
-``created_models``
-    A list of the model classes from any app which :djadmin:`syncdb` has
-    created so far.
-
 ``verbosity``
     Indicates how much information manage.py is printing on screen. See
     the :djadminopt:`--verbosity` flag for details.
 
-    Functions which listen for :data:`post_syncdb` should adjust what they
+    Functions which listen for :data:`post_migrate` should adjust what they
     output to the screen based on the value of this argument.
 
 ``interactive``
@@ -459,14 +470,34 @@ Arguments sent with this signal:
 
 For example, ``yourapp/management/__init__.py`` could be written like::
 
-    from django.db.models.signals import post_syncdb
+    from django.db.models.signals import post_migrate
     import yourapp.models
 
     def my_callback(sender, **kwargs):
         # Your specific logic here
         pass
 
-    post_syncdb.connect(my_callback, sender=yourapp.models)
+    post_migrate.connect(my_callback, sender=yourapp.models)
+
+
+post_syncdb
+-----------
+
+.. data:: django.db.models.signals.post_syncdb
+   :module:
+
+.. deprecated:: 1.7
+
+    This signal has been renamed to :data:`~django.db.models.signals.post_migrate`.
+
+Alias of :data:`django.db.models.signals.post_migrate`. As long as this alias
+is present, for backwards-compatability this signal has an extra argument it sends:
+
+``created_models``
+    A list of the model classes from any app which :djadmin:`migrate` has
+    created, **only if the app has no migrations**.
+
+
 
 Request/response signals
 ========================
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index 4d7f22aaa2..6d9ea8d5c1 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -182,7 +182,7 @@ Advanced features of ``TransactionTestCase``
 
     By default, ``available_apps`` is set to ``None``. After each test, Django
     calls :djadmin:`flush` to reset the database state. This empties all tables
-    and emits the :data:`~django.db.models.signals.post_syncdb` signal, which
+    and emits the :data:`~django.db.models.signals.post_migrate` signal, which
     re-creates one content type and three permissions for each model. This
     operation gets expensive proportionally to the number of models.
 
@@ -190,13 +190,13 @@ Advanced features of ``TransactionTestCase``
     behave as if only the models from these applications were available. The
     behavior of ``TransactionTestCase`` changes as follows:
 
-    - :data:`~django.db.models.signals.post_syncdb` is fired before each
+    - :data:`~django.db.models.signals.post_migrate` is fired before each
       test to create the content types and permissions for each model in
       available apps, in case they're missing.
     - After each test, Django empties only tables corresponding to models in
       available apps. However, at the database level, truncation may cascade to
       related models in unavailable apps. Furthermore
-      :data:`~django.db.models.signals.post_syncdb` isn't fired; it will be
+      :data:`~django.db.models.signals.post_migrate` isn't fired; it will be
       fired by the next ``TransactionTestCase``, after the correct set of
       applications is selected.
 
@@ -205,10 +205,10 @@ Advanced features of ``TransactionTestCase``
     cause unrelated tests to fail. Be careful with tests that use sessions;
     the default session engine stores them in the database.
 
-    Since :data:`~django.db.models.signals.post_syncdb` isn't emitted after
+    Since :data:`~django.db.models.signals.post_migrate` isn't emitted after
     flushing the database, its state after a ``TransactionTestCase`` isn't the
     same as after a ``TestCase``: it's missing the rows created by listeners
-    to :data:`~django.db.models.signals.post_syncdb`. Considering the
+    to :data:`~django.db.models.signals.post_migrate`. Considering the
     :ref:`order in which tests are executed <order-of-tests>`, this isn't an
     issue, provided either all ``TransactionTestCase`` in a given test suite
     declare ``available_apps``, or none of them.