Removed pre_syncdb and post_syncdb signals per deprecation timeline.

This commit is contained in:
Tim Graham 2014-12-26 11:19:43 -05:00
parent fed25f1105
commit f4f24d30e0
6 changed files with 9 additions and 143 deletions

View file

@ -405,52 +405,6 @@ Arguments sent with this signal:
``using``
The alias of database on which a command will operate.
pre_syncdb
----------
.. data:: django.db.models.signals.pre_syncdb
:module:
.. deprecated:: 1.7
This signal has been replaced by :data:`~django.db.models.signals.pre_migrate`.
Sent by the :djadmin:`syncdb` command before it starts to install an
application.
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.
``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
output to the screen based on the value of this argument.
``interactive``
If ``interactive`` is ``True``, it's safe to prompt the user to input
things on the command line. If ``interactive`` is ``False``, functions
which listen for this signal should not try to prompt for anything.
For example, the :mod:`django.contrib.auth` app only prompts to create a
superuser when ``interactive`` is ``True``.
``db``
The alias of database on which a command will operate.
post_migrate
------------
@ -518,67 +472,6 @@ For example, you could register a callback in an
when settings are overridden) and such signals should be connected for each
new ``AppConfig`` instance.
post_syncdb
-----------
.. data:: django.db.models.signals.post_syncdb
:module:
.. deprecated:: 1.7
This signal has been replaced by :data:`~django.db.models.signals.post_migrate`.
Sent by the :djadmin:`syncdb` command after it installs an application, and the
:djadmin:`flush` command.
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.
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.
``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
output to the screen based on the value of this argument.
``interactive``
If ``interactive`` is ``True``, it's safe to prompt the user to input
things on the command line. If ``interactive`` is ``False``, functions
which listen for this signal should not try to prompt for anything.
For example, the :mod:`django.contrib.auth` app only prompts to create a
superuser when ``interactive`` is ``True``.
``db``
The database alias used for synchronization. Defaults to the ``default``
database.
For example, ``yourapp/management/__init__.py`` could be written like::
from django.db.models.signals import post_syncdb
import yourapp.models
def my_callback(sender, **kwargs):
# Your specific logic here
pass
post_syncdb.connect(my_callback, sender=yourapp.models)
Request/response signals
========================

View file

@ -51,8 +51,8 @@ but a few of the key features are:
* A new ``makemigrations`` command provides an easy way to autodetect changes
to your models and make migrations for them.
:data:`~django.db.models.signals.pre_syncdb` and
:data:`~django.db.models.signals.post_syncdb` have been deprecated,
``django.db.models.signals.pre_syncdb`` and
``django.db.models.signals.post_syncdb`` have been deprecated,
to be replaced by :data:`~django.db.models.signals.pre_migrate` and
:data:`~django.db.models.signals.post_migrate` respectively. These
new signals have slightly different arguments. Check the