Removed an unncessary docs cross-reference for call_command().
This commit is contained in:
parent
555f8e9d5c
commit
a7752780d9
|
@ -309,7 +309,7 @@ the :meth:`~BaseCommand.handle` method must be implemented.
|
||||||
.. admonition:: Calling a management command in your code
|
.. admonition:: Calling a management command in your code
|
||||||
|
|
||||||
``execute()`` should not be called directly from your code to execute a
|
``execute()`` should not be called directly from your code to execute a
|
||||||
command. Use :ref:`call_command <call-command>` instead.
|
command. Use :func:`~django.core.management.call_command` instead.
|
||||||
|
|
||||||
.. method:: BaseCommand.handle(*args, **options)
|
.. method:: BaseCommand.handle(*args, **options)
|
||||||
|
|
||||||
|
@ -374,5 +374,6 @@ message to the appropriate output stream (i.e., stderr); as a result, raising
|
||||||
this exception (with a sensible description of the error) is the preferred way
|
this exception (with a sensible description of the error) is the preferred way
|
||||||
to indicate that something has gone wrong in the execution of a command.
|
to indicate that something has gone wrong in the execution of a command.
|
||||||
|
|
||||||
If a management command is called from code through :ref:`call_command
|
If a management command is called from code through
|
||||||
<call-command>`, it's up to you to catch the exception when needed.
|
:func:`~django.core.management.call_command`, it's up to you to catch the
|
||||||
|
exception when needed.
|
||||||
|
|
|
@ -1755,8 +1755,6 @@ See :doc:`/howto/custom-management-commands` for how to add customized actions.
|
||||||
Running management commands from your code
|
Running management commands from your code
|
||||||
==========================================
|
==========================================
|
||||||
|
|
||||||
.. _call-command:
|
|
||||||
|
|
||||||
.. function:: django.core.management.call_command(name, *args, **options)
|
.. function:: django.core.management.call_command(name, *args, **options)
|
||||||
|
|
||||||
To call a management command from code use ``call_command``.
|
To call a management command from code use ``call_command``.
|
||||||
|
|
|
@ -254,8 +254,9 @@ Django 1.5 also includes several smaller improvements worth noting:
|
||||||
* The generic views support OPTIONS requests.
|
* The generic views support OPTIONS requests.
|
||||||
|
|
||||||
* Management commands do not raise ``SystemExit`` any more when called by code
|
* Management commands do not raise ``SystemExit`` any more when called by code
|
||||||
from :ref:`call_command <call-command>`. Any exception raised by the command
|
from :func:`~django.core.management.call_command`. Any exception raised by
|
||||||
(mostly :exc:`~django.core.management.CommandError`) is propagated.
|
the command (mostly :exc:`~django.core.management.CommandError`) is
|
||||||
|
propagated.
|
||||||
|
|
||||||
Moreover, when you output errors or messages in your custom commands, you
|
Moreover, when you output errors or messages in your custom commands, you
|
||||||
should now use ``self.stdout.write('message')`` and
|
should now use ``self.stdout.write('message')`` and
|
||||||
|
|
|
@ -429,12 +429,12 @@ Management Commands
|
||||||
introspect :class:`~django.db.models.AutoField` for MySQL and PostgreSQL
|
introspect :class:`~django.db.models.AutoField` for MySQL and PostgreSQL
|
||||||
databases.
|
databases.
|
||||||
|
|
||||||
* When calling management commands from code through :ref:`call_command
|
* When calling management commands with options using
|
||||||
<call-command>` and passing options, the option name can match the command
|
:func:`~django.core.management.call_command`, the option name can match the
|
||||||
line option name (without the initial dashes) or the final option destination
|
command line option name (without the initial dashes) or the final option
|
||||||
variable name, but in either case, the resulting option received by the
|
destination variable name, but in either case, the resulting option received
|
||||||
command is now always the ``dest`` name specified in the command option
|
by the command is now always the ``dest`` name specified in the command
|
||||||
definition (as long as the command uses the new :py:mod:`argparse` module).
|
option definition (as long as the command uses the :mod:`argparse` module).
|
||||||
|
|
||||||
* The :djadmin:`dbshell` command now supports MySQL's optional SSL certificate
|
* The :djadmin:`dbshell` command now supports MySQL's optional SSL certificate
|
||||||
authority setting (``--ssl-ca``).
|
authority setting (``--ssl-ca``).
|
||||||
|
@ -1121,8 +1121,8 @@ Miscellaneous
|
||||||
class name found in the :setting:`BACKEND <CACHES-BACKEND>` key of the
|
class name found in the :setting:`BACKEND <CACHES-BACKEND>` key of the
|
||||||
:setting:`CACHES` setting.
|
:setting:`CACHES` setting.
|
||||||
|
|
||||||
* By default, :ref:`call_command <call-command>` now always skips the check
|
* By default, :func:`~django.core.management.call_command` now always skips the
|
||||||
framework (unless you pass it ``skip_checks=False``).
|
check framework (unless you pass it ``skip_checks=False``).
|
||||||
|
|
||||||
* When iterating over lines, :class:`~django.core.files.File` now uses
|
* When iterating over lines, :class:`~django.core.files.File` now uses
|
||||||
`universal newlines`_. The following are recognized as ending a line: the
|
`universal newlines`_. The following are recognized as ending a line: the
|
||||||
|
|
Loading…
Reference in New Issue