Fixed #15207 -- Added versionadded directives for the "using" argument sent by signals, and cleaned up some incidental indentation/formatting inconsistencies. Thanks to Keryn Knight for the report.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@15443 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Gabriel Hurley
parent
f6e38f3800
commit
608877c066
|
|
@ -51,14 +51,14 @@ of the model's :meth:`~django.db.models.Model.__init__` method.
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The model class that just had an instance created.
|
||||
|
||||
``args``
|
||||
``args``
|
||||
A list of positional arguments passed to
|
||||
:meth:`~django.db.models.Model.__init__`:
|
||||
|
||||
``kwargs``
|
||||
``kwargs``
|
||||
A dictionary of keyword arguments passed to
|
||||
:meth:`~django.db.models.Model.__init__`:.
|
||||
|
||||
|
|
@ -91,10 +91,10 @@ Like pre_init, but this one is sent when the :meth:`~django.db.models.Model.__in
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
As above: the model class that just had an instance created.
|
||||
|
||||
``instance``
|
||||
``instance``
|
||||
The actual instance of the model that's just been created.
|
||||
|
||||
pre_save
|
||||
|
|
@ -108,13 +108,15 @@ method.
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The model class.
|
||||
|
||||
``instance``
|
||||
``instance``
|
||||
The actual instance being saved.
|
||||
|
||||
``using``
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
post_save
|
||||
|
|
@ -128,16 +130,18 @@ Like :data:`pre_save`, but sent at the end of the
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The model class.
|
||||
|
||||
``instance``
|
||||
``instance``
|
||||
The actual instance being saved.
|
||||
|
||||
``created``
|
||||
``created``
|
||||
A boolean; ``True`` if a new record was created.
|
||||
|
||||
``using``
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
pre_delete
|
||||
|
|
@ -151,13 +155,15 @@ method.
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The model class.
|
||||
|
||||
``instance``
|
||||
``instance``
|
||||
The actual instance being deleted.
|
||||
|
||||
``using``
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
post_delete
|
||||
|
|
@ -171,16 +177,18 @@ Like :data:`pre_delete`, but sent at the end of the
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The model class.
|
||||
|
||||
``instance``
|
||||
``instance``
|
||||
The actual instance being deleted.
|
||||
|
||||
Note that the object will no longer be in the database, so be very
|
||||
careful what you do with this instance.
|
||||
|
||||
``using``
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
m2m_changed
|
||||
|
|
@ -199,18 +207,18 @@ when it comes to tracking changes to models, it is included here.
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The intermediate model class describing the :class:`ManyToManyField`.
|
||||
This class is automatically created when a many-to-many field is
|
||||
defined; you can access it using the ``through`` attribute on the
|
||||
many-to-many field.
|
||||
|
||||
``instance``
|
||||
``instance``
|
||||
The instance whose many-to-many relation is updated. This can be an
|
||||
instance of the ``sender``, or of the class the :class:`ManyToManyField`
|
||||
is related to.
|
||||
|
||||
``action``
|
||||
``action``
|
||||
A string indicating the type of update that is done on the relation.
|
||||
This can be one of the following:
|
||||
|
||||
|
|
@ -227,22 +235,24 @@ Arguments sent with this signal:
|
|||
``"post_clear"``
|
||||
Sent *after* the relation is cleared
|
||||
|
||||
``reverse``
|
||||
``reverse``
|
||||
Indicates which side of the relation is updated (i.e., if it is the
|
||||
forward or reverse relation that is being modified).
|
||||
|
||||
``model``
|
||||
``model``
|
||||
The class of the objects that are added to, removed from or cleared
|
||||
from the relation.
|
||||
|
||||
``pk_set``
|
||||
``pk_set``
|
||||
For the ``pre_add``, ``post_add``, ``pre_remove`` and ``post_remove``
|
||||
actions, this is a list of primary key values that have been added to
|
||||
or removed from the relation.
|
||||
|
||||
For the ``pre_clear`` and ``post_clear`` actions, this is ``None``.
|
||||
|
||||
``using``
|
||||
.. versionadded:: 1.3
|
||||
|
||||
``using``
|
||||
The database alias being used.
|
||||
|
||||
For example, if a ``Pizza`` can have multiple ``Topping`` objects, modeled
|
||||
|
|
@ -351,26 +361,26 @@ handlers are registered anywhere else they may not be loaded by
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``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``
|
||||
``app``
|
||||
Same as ``sender``.
|
||||
|
||||
``created_models``
|
||||
``created_models``
|
||||
A list of the model classes from any app which :djadmin:`syncdb` has
|
||||
created so far.
|
||||
|
||||
``verbosity``
|
||||
``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``
|
||||
``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.
|
||||
|
|
@ -407,7 +417,7 @@ Sent when Django begins processing an HTTP request.
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The handler class -- e.g.
|
||||
:class:`django.core.handlers.wsgi.WsgiHandler` -- that handled
|
||||
the request.
|
||||
|
|
@ -422,7 +432,7 @@ Sent when Django finishes processing an HTTP request.
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The handler class, as above.
|
||||
|
||||
got_request_exception
|
||||
|
|
@ -435,10 +445,10 @@ This signal is sent whenever Django encounters an exception while processing an
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
``sender``
|
||||
``sender``
|
||||
The handler class, as above.
|
||||
|
||||
``request``
|
||||
``request``
|
||||
The :class:`~django.http.HttpRequest` object.
|
||||
|
||||
Test signals
|
||||
|
|
@ -460,13 +470,13 @@ normal operation of a Django server -- it is only available during testing.
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
sender
|
||||
``sender``
|
||||
The :class:`~django.template.Template` object which was rendered.
|
||||
|
||||
template
|
||||
``template``
|
||||
Same as sender
|
||||
|
||||
context
|
||||
``context``
|
||||
The :class:`~django.template.Context` with which the template was
|
||||
rendered.
|
||||
|
||||
|
|
@ -494,12 +504,12 @@ connection commands to the SQL backend.
|
|||
|
||||
Arguments sent with this signal:
|
||||
|
||||
sender
|
||||
``sender``
|
||||
The database wrapper class -- i.e.
|
||||
:class:`django.db.backends.postgresql_psycopg2.DatabaseWrapper` or
|
||||
:class:`django.db.backends.mysql.DatabaseWrapper`, etc.
|
||||
|
||||
connection
|
||||
``connection``
|
||||
The database connection that was opened. This can be used in a
|
||||
multiple-database configuration to differentiate connection signals
|
||||
from different databases.
|
||||
|
|
|
|||
Loading…
Reference in New Issue