2014-07-26 11:21:52 +00:00
|
|
|
|
==========================
|
|
|
|
|
django-admin and manage.py
|
|
|
|
|
==========================
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
``django-admin`` is Django's command-line utility for administrative tasks.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
This document outlines all it can do.
|
|
|
|
|
|
2006-01-11 02:06:27 +00:00
|
|
|
|
In addition, ``manage.py`` is automatically created in each Django project.
|
2014-07-26 11:21:52 +00:00
|
|
|
|
``manage.py`` is a thin wrapper around ``django-admin`` that takes care of
|
2014-11-25 05:20:46 +00:00
|
|
|
|
several things for you before delegating to ``django-admin``:
|
2006-01-11 02:06:27 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* It puts your project's package on ``sys.path``.
|
2006-01-11 02:06:27 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* It sets the :envvar:`DJANGO_SETTINGS_MODULE` environment variable so that
|
|
|
|
|
it points to your project's ``settings.py`` file.
|
2006-01-11 02:06:27 +00:00
|
|
|
|
|
2014-04-26 16:32:17 +00:00
|
|
|
|
* It calls :func:`django.setup()` to initialize various internals of Django.
|
2013-12-30 14:42:15 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
The ``django-admin`` script should be on your system path if you installed
|
2008-08-23 22:25:40 +00:00
|
|
|
|
Django via its ``setup.py`` utility. If it's not on your path, you can find it
|
|
|
|
|
in ``site-packages/django/bin`` within your Python installation. Consider
|
2007-02-10 09:07:54 +00:00
|
|
|
|
symlinking it from some place on your path, such as ``/usr/local/bin``.
|
|
|
|
|
|
2008-08-23 22:25:40 +00:00
|
|
|
|
For Windows users, who do not have symlinking functionality available, you can
|
2014-07-26 11:21:52 +00:00
|
|
|
|
copy ``django-admin.exe`` to a location on your existing path or edit the
|
2008-08-23 22:25:40 +00:00
|
|
|
|
``PATH`` settings (under ``Settings - Control Panel - System - Advanced -
|
|
|
|
|
Environment...``) to point to its installed location.
|
2006-05-02 01:31:56 +00:00
|
|
|
|
|
2006-01-11 02:06:27 +00:00
|
|
|
|
Generally, when working on a single Django project, it's easier to use
|
2014-07-26 11:21:52 +00:00
|
|
|
|
``manage.py`` than ``django-admin``. If you need to switch between multiple
|
|
|
|
|
Django settings files, use ``django-admin`` with
|
2013-04-12 10:10:26 +00:00
|
|
|
|
:envvar:`DJANGO_SETTINGS_MODULE` or the :djadminopt:`--settings` command line
|
|
|
|
|
option.
|
2006-01-11 02:06:27 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
The command-line examples throughout this document use ``django-admin`` to
|
2007-04-09 01:44:26 +00:00
|
|
|
|
be consistent, but any example can use ``manage.py`` just as well.
|
|
|
|
|
|
2005-08-10 20:24:51 +00:00
|
|
|
|
Usage
|
|
|
|
|
=====
|
|
|
|
|
|
2015-02-19 03:19:21 +00:00
|
|
|
|
.. code-block:: console
|
2006-01-11 05:54:13 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
$ django-admin <command> [options]
|
2013-12-25 19:54:14 +00:00
|
|
|
|
$ manage.py <command> [options]
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2010-10-23 16:37:51 +00:00
|
|
|
|
``command`` should be one of the commands listed in this document.
|
2007-09-09 21:57:59 +00:00
|
|
|
|
``options``, which is optional, should be zero or more of the options available
|
2010-10-23 16:37:51 +00:00
|
|
|
|
for the given command.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2007-09-09 21:57:59 +00:00
|
|
|
|
Getting runtime help
|
|
|
|
|
--------------------
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2012-02-07 18:46:29 +00:00
|
|
|
|
.. django-admin:: help
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
Run ``django-admin help`` to display usage information and a list of the
|
2012-02-07 18:46:29 +00:00
|
|
|
|
commands provided by each application.
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
Run ``django-admin help --commands`` to display a list of all available
|
2012-02-07 18:46:29 +00:00
|
|
|
|
commands.
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
Run ``django-admin help <command>`` to display a description of the given
|
2012-02-07 18:46:29 +00:00
|
|
|
|
command and a list of its available options.
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
|
|
|
|
App names
|
|
|
|
|
---------
|
|
|
|
|
|
2010-10-23 16:37:51 +00:00
|
|
|
|
Many commands take a list of "app names." An "app name" is the basename of
|
2011-05-29 17:41:04 +00:00
|
|
|
|
the package containing your models. For example, if your :setting:`INSTALLED_APPS`
|
2007-09-09 21:57:59 +00:00
|
|
|
|
contains the string ``'mysite.blog'``, the app name is ``blog``.
|
|
|
|
|
|
|
|
|
|
Determining the version
|
|
|
|
|
-----------------------
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2012-02-07 18:46:29 +00:00
|
|
|
|
.. django-admin:: version
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
Run ``django-admin version`` to display the current Django version.
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2012-02-09 08:37:33 +00:00
|
|
|
|
The output follows the schema described in :pep:`386`::
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2012-02-09 08:37:33 +00:00
|
|
|
|
1.4.dev17026
|
|
|
|
|
1.4a1
|
|
|
|
|
1.4
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2008-08-23 22:25:40 +00:00
|
|
|
|
Displaying debug output
|
|
|
|
|
-----------------------
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
Use :djadminopt:`--verbosity` to specify the amount of notification and debug information
|
2014-07-26 11:21:52 +00:00
|
|
|
|
that ``django-admin`` should print to the console. For more details, see the
|
2009-11-12 13:58:32 +00:00
|
|
|
|
documentation for the :djadminopt:`--verbosity` option.
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2010-10-23 16:37:51 +00:00
|
|
|
|
Available commands
|
|
|
|
|
==================
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2014-01-20 02:45:21 +00:00
|
|
|
|
check <appname appname ...>
|
|
|
|
|
---------------------------
|
2013-06-14 23:02:29 +00:00
|
|
|
|
|
2013-07-12 16:48:49 +00:00
|
|
|
|
.. django-admin:: check
|
2013-06-14 23:02:29 +00:00
|
|
|
|
|
2014-01-20 02:45:21 +00:00
|
|
|
|
Uses the :doc:`system check framework </ref/checks>` to inspect
|
|
|
|
|
the entire Django project for common problems.
|
|
|
|
|
|
|
|
|
|
The system check framework will confirm that there aren't any problems with
|
|
|
|
|
your installed models or your admin registrations. It will also provide warnings
|
|
|
|
|
of common compatibility problems introduced by upgrading Django to a new version.
|
|
|
|
|
Custom checks may be introduced by other libraries and applications.
|
|
|
|
|
|
2014-01-20 05:13:16 +00:00
|
|
|
|
By default, all apps will be checked. You can check a subset of apps by providing
|
2014-01-20 02:45:21 +00:00
|
|
|
|
a list of app labels as arguments::
|
2013-06-15 17:14:30 +00:00
|
|
|
|
|
2014-01-20 12:46:21 +00:00
|
|
|
|
python manage.py check auth admin myapp
|
2013-06-14 23:02:29 +00:00
|
|
|
|
|
2014-01-20 02:45:21 +00:00
|
|
|
|
If you do not specify any app, all apps will be checked.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --tag <tagname>
|
|
|
|
|
|
|
|
|
|
The :doc:`system check framework </ref/checks>` performs many different
|
|
|
|
|
types of checks. These check types are categorized with tags. You can use these tags
|
|
|
|
|
to restrict the checks performed to just those in a particular category. For example,
|
|
|
|
|
to perform only security and compatibility checks, you would run::
|
|
|
|
|
|
2014-01-20 12:46:21 +00:00
|
|
|
|
python manage.py check --tag security --tag compatibility
|
2013-06-14 23:02:29 +00:00
|
|
|
|
|
2014-04-10 13:43:55 +00:00
|
|
|
|
.. django-admin-option:: --list-tags
|
|
|
|
|
|
|
|
|
|
List all available tags.
|
|
|
|
|
|
2014-09-12 18:50:36 +00:00
|
|
|
|
.. django-admin-option:: --deploy
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
The ``--deploy`` option activates some additional checks that are only relevant
|
|
|
|
|
in a deployment setting.
|
|
|
|
|
|
|
|
|
|
You can use this option in your local development environment, but since your
|
|
|
|
|
local development settings module may not have many of your production settings,
|
|
|
|
|
you will probably want to point the ``check`` command at a different settings
|
|
|
|
|
module, either by setting the ``DJANGO_SETTINGS_MODULE`` environment variable,
|
|
|
|
|
or by passing the ``--settings`` option::
|
|
|
|
|
|
|
|
|
|
python manage.py check --deploy --settings=production_settings
|
|
|
|
|
|
|
|
|
|
Or you could run it directly on a production or staging deployment to verify
|
|
|
|
|
that the correct settings are in use (omitting ``--settings``). You could even
|
|
|
|
|
make it part of your integration test suite.
|
|
|
|
|
|
2008-07-06 06:39:44 +00:00
|
|
|
|
compilemessages
|
|
|
|
|
---------------
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: compilemessages
|
|
|
|
|
|
2014-04-09 03:58:40 +00:00
|
|
|
|
Compiles .po files created by :djadmin:`makemessages` to .mo files for use with
|
2010-08-19 19:27:44 +00:00
|
|
|
|
the builtin gettext support. See :doc:`/topics/i18n/index`.
|
2008-07-06 06:39:44 +00:00
|
|
|
|
|
2012-06-07 09:23:25 +00:00
|
|
|
|
Use the :djadminopt:`--locale` option (or its shorter version ``-l``) to
|
|
|
|
|
specify the locale(s) to process. If not provided, all locales are processed.
|
2008-07-06 06:39:44 +00:00
|
|
|
|
|
2014-05-01 07:03:24 +00:00
|
|
|
|
Use the :djadminopt:`--exclude` option (or its shorter version ``-x``) to
|
2014-03-24 13:03:06 +00:00
|
|
|
|
specify the locale(s) to exclude from processing. If not provided, no locales
|
|
|
|
|
are excluded.
|
|
|
|
|
|
2014-11-15 22:56:37 +00:00
|
|
|
|
You can pass ``--use-fuzzy`` option (or ``-f``) to include fuzzy translations
|
|
|
|
|
into compiled files.
|
|
|
|
|
|
2015-04-16 11:55:37 +00:00
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
``compilemessages`` now matches the operation of :djadmin:`makemessages`,
|
|
|
|
|
scanning the project tree for ``.po`` files to compile.
|
|
|
|
|
|
2014-11-15 22:56:37 +00:00
|
|
|
|
.. versionchanged:: 1.8
|
|
|
|
|
|
|
|
|
|
Added ``--exclude`` and ``--use-fuzzy`` options.
|
|
|
|
|
|
2008-07-06 06:39:44 +00:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin compilemessages --locale=pt_BR
|
2014-11-15 22:56:37 +00:00
|
|
|
|
django-admin compilemessages --locale=pt_BR --locale=fr -f
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin compilemessages -l pt_BR
|
2014-11-15 22:56:37 +00:00
|
|
|
|
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin compilemessages --exclude=pt_BR
|
|
|
|
|
django-admin compilemessages --exclude=pt_BR --exclude=fr
|
|
|
|
|
django-admin compilemessages -x pt_BR
|
|
|
|
|
django-admin compilemessages -x pt_BR -x fr
|
2012-06-07 09:23:25 +00:00
|
|
|
|
|
2008-10-02 12:57:13 +00:00
|
|
|
|
createcachetable
|
2008-08-23 22:25:40 +00:00
|
|
|
|
----------------
|
2005-09-25 22:03:30 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: createcachetable
|
2005-09-25 22:03:30 +00:00
|
|
|
|
|
2015-01-26 20:39:52 +00:00
|
|
|
|
Creates the cache tables for use with the database cache backend using the
|
|
|
|
|
information from your settings file. See :doc:`/topics/cache` for more
|
|
|
|
|
information.
|
2005-09-25 22:03:30 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--database` option can be used to specify the database
|
2015-01-26 20:39:52 +00:00
|
|
|
|
onto which the cache table will be installed, but since this information is
|
|
|
|
|
pulled from your settings by default, it's typically not needed.
|
2013-01-05 22:43:01 +00:00
|
|
|
|
|
2015-04-01 21:33:27 +00:00
|
|
|
|
The :djadminopt:`--dry-run` option will print the SQL that would be run without
|
|
|
|
|
actually running it, so you can customize it or use the migrations framework.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
The ``--dry-run`` option was added.
|
|
|
|
|
|
2008-06-11 04:34:03 +00:00
|
|
|
|
dbshell
|
|
|
|
|
-------
|
|
|
|
|
|
2008-08-23 22:25:40 +00:00
|
|
|
|
.. django-admin:: dbshell
|
|
|
|
|
|
2008-06-11 04:34:03 +00:00
|
|
|
|
Runs the command-line client for the database engine specified in your
|
2009-12-22 15:18:51 +00:00
|
|
|
|
``ENGINE`` setting, with the connection parameters specified in your
|
2011-05-29 17:41:04 +00:00
|
|
|
|
:setting:`USER`, :setting:`PASSWORD`, etc., settings.
|
2008-06-11 04:34:03 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* For PostgreSQL, this runs the ``psql`` command-line client.
|
|
|
|
|
* For MySQL, this runs the ``mysql`` command-line client.
|
|
|
|
|
* For SQLite, this runs the ``sqlite3`` command-line client.
|
2008-06-11 04:34:03 +00:00
|
|
|
|
|
|
|
|
|
This command assumes the programs are on your ``PATH`` so that a simple call to
|
|
|
|
|
the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in
|
|
|
|
|
the right place. There's no way to specify the location of the program
|
|
|
|
|
manually.
|
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--database` option can be used to specify the database
|
|
|
|
|
onto which to open a shell.
|
|
|
|
|
|
2006-05-02 01:31:56 +00:00
|
|
|
|
diffsettings
|
|
|
|
|
------------
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2008-08-23 22:25:40 +00:00
|
|
|
|
.. django-admin:: diffsettings
|
|
|
|
|
|
2006-05-02 01:31:56 +00:00
|
|
|
|
Displays differences between the current settings file and Django's default
|
2008-10-02 12:57:13 +00:00
|
|
|
|
settings.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2006-05-02 01:31:56 +00:00
|
|
|
|
Settings that don't appear in the defaults are followed by ``"###"``. For
|
2011-05-29 17:41:04 +00:00
|
|
|
|
example, the default settings don't define :setting:`ROOT_URLCONF`, so
|
|
|
|
|
:setting:`ROOT_URLCONF` is followed by ``"###"`` in the output of
|
|
|
|
|
``diffsettings``.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2013-03-17 19:48:30 +00:00
|
|
|
|
The :djadminopt:`--all` option may be provided to display all settings, even
|
|
|
|
|
if they have Django's default value. Such settings are prefixed by ``"###"``.
|
|
|
|
|
|
2013-12-28 08:53:02 +00:00
|
|
|
|
dumpdata <app_label app_label app_label.Model ...>
|
|
|
|
|
--------------------------------------------------
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: dumpdata
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
2007-09-09 21:57:59 +00:00
|
|
|
|
Outputs to standard output all data in the database associated with the named
|
2007-03-01 13:11:08 +00:00
|
|
|
|
application(s).
|
|
|
|
|
|
|
|
|
|
If no application name is provided, all installed applications will be dumped.
|
|
|
|
|
|
2013-11-18 18:25:28 +00:00
|
|
|
|
The output of ``dumpdata`` can be used as input for :djadmin:`loaddata`.
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
2007-12-17 11:11:34 +00:00
|
|
|
|
Note that ``dumpdata`` uses the default manager on the model for selecting the
|
2008-08-23 22:25:40 +00:00
|
|
|
|
records to dump. If you're using a :ref:`custom manager <custom-managers>` as
|
|
|
|
|
the default manager and it filters some of the available records, not all of the
|
|
|
|
|
objects will be dumped.
|
2007-12-17 09:09:08 +00:00
|
|
|
|
|
2010-08-30 11:58:26 +00:00
|
|
|
|
The :djadminopt:`--all` option may be provided to specify that
|
|
|
|
|
``dumpdata`` should use Django's base manager, dumping records which
|
|
|
|
|
might otherwise be filtered or modified by a custom manager.
|
|
|
|
|
|
2008-08-23 22:25:40 +00:00
|
|
|
|
.. django-admin-option:: --format <fmt>
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
By default, ``dumpdata`` will format its output in JSON, but you can use the
|
|
|
|
|
``--format`` option to specify another format. Currently supported formats
|
|
|
|
|
are listed in :ref:`serialization-formats`.
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2008-08-23 22:25:40 +00:00
|
|
|
|
.. django-admin-option:: --indent <num>
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
By default, ``dumpdata`` will output all data on a single line. This isn't
|
|
|
|
|
easy for humans to read, so you can use the ``--indent`` option to
|
|
|
|
|
pretty-print the output with a number of indentation spaces.
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--exclude` option may be provided to prevent specific
|
2013-12-28 08:53:02 +00:00
|
|
|
|
applications or models (specified as in the form of ``app_label.ModelName``)
|
|
|
|
|
from being dumped. If you specify a model name to ``dumpdata``, the dumped
|
|
|
|
|
output will be restricted to that model, rather than the entire application.
|
|
|
|
|
You can also mix application names and model names.
|
2009-02-28 05:35:22 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--database` option can be used to specify the database
|
2012-04-06 18:55:42 +00:00
|
|
|
|
from which data will be dumped.
|
2009-12-22 15:18:51 +00:00
|
|
|
|
|
2012-08-01 01:49:01 +00:00
|
|
|
|
.. django-admin-option:: --natural-foreign
|
|
|
|
|
|
|
|
|
|
When this option is specified, Django will use the ``natural_key()`` model
|
|
|
|
|
method to serialize any foreign key and many-to-many relationship to objects of
|
|
|
|
|
the type that defines the method. If you are dumping ``contrib.auth``
|
|
|
|
|
``Permission`` objects or ``contrib.contenttypes`` ``ContentType`` objects, you
|
|
|
|
|
should probably be using this flag. See the :ref:`natural keys
|
|
|
|
|
<topics-serialization-natural-keys>` documentation for more details on this
|
|
|
|
|
and the next option.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --natural-primary
|
|
|
|
|
|
|
|
|
|
When this option is specified, Django will not provide the primary key in the
|
|
|
|
|
serialized data of this object since it can be calculated during
|
|
|
|
|
deserialization.
|
|
|
|
|
|
2013-05-19 10:39:14 +00:00
|
|
|
|
.. django-admin-option:: --pks
|
|
|
|
|
|
|
|
|
|
By default, ``dumpdata`` will output all the records of the model, but
|
2013-07-28 01:45:25 +00:00
|
|
|
|
you can use the ``--pks`` option to specify a comma separated list of
|
2013-05-19 10:39:14 +00:00
|
|
|
|
primary keys on which to filter. This is only available when dumping
|
|
|
|
|
one model.
|
|
|
|
|
|
2014-03-23 05:10:12 +00:00
|
|
|
|
.. django-admin-option:: --output
|
|
|
|
|
|
2014-03-25 13:43:51 +00:00
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
2014-03-23 05:10:12 +00:00
|
|
|
|
By default ``dumpdata`` will output all the serialized data to standard output.
|
2015-05-07 23:41:42 +00:00
|
|
|
|
This option allows you to specify the file to which the data is to be written.
|
2014-03-23 05:10:12 +00:00
|
|
|
|
|
2007-03-01 13:11:08 +00:00
|
|
|
|
flush
|
|
|
|
|
-----
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: flush
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2015-04-27 17:17:52 +00:00
|
|
|
|
Removes all data from the database and re-executes any post-synchronization
|
|
|
|
|
handlers. The table of which migrations have been applied is not cleared.
|
|
|
|
|
|
|
|
|
|
If you would rather start from an empty database and re-run all migrations, you
|
|
|
|
|
should drop and recreate the database and then run :djadmin:`migrate` instead.
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
The :djadminopt:`--noinput` option may be provided to suppress all user
|
|
|
|
|
prompts.
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--database` option may be used to specify the database
|
|
|
|
|
to flush.
|
|
|
|
|
|
2006-05-02 01:31:56 +00:00
|
|
|
|
inspectdb
|
|
|
|
|
---------
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: inspectdb
|
|
|
|
|
|
2015-06-30 18:23:29 +00:00
|
|
|
|
Introspects the database tables in the database pointed-to by the
|
2011-05-29 17:41:04 +00:00
|
|
|
|
:setting:`NAME` setting and outputs a Django model module (a ``models.py``
|
2006-05-02 01:31:56 +00:00
|
|
|
|
file) to standard output.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
|
|
|
|
Use this if you have a legacy database with which you'd like to use Django.
|
2015-06-30 18:23:29 +00:00
|
|
|
|
The script will inspect the database and create a model for each table within
|
|
|
|
|
it.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2006-02-04 20:08:30 +00:00
|
|
|
|
As you might expect, the created models will have an attribute for every field
|
2015-06-30 18:23:29 +00:00
|
|
|
|
in the table. Note that ``inspectdb`` has a few special cases in its field-name
|
|
|
|
|
output:
|
2006-02-04 20:08:30 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* If ``inspectdb`` cannot map a column's type to a model field type, it'll
|
|
|
|
|
use ``TextField`` and will insert the Python comment
|
|
|
|
|
``'This field type is a guess.'`` next to the field in the generated
|
|
|
|
|
model.
|
2006-02-04 20:08:30 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* If the database column name is a Python reserved word (such as
|
|
|
|
|
``'pass'``, ``'class'`` or ``'for'``), ``inspectdb`` will append
|
|
|
|
|
``'_field'`` to the attribute name. For example, if a table has a column
|
|
|
|
|
``'for'``, the generated model will have a field ``'for_field'``, with
|
|
|
|
|
the ``db_column`` attribute set to ``'for'``. ``inspectdb`` will insert
|
|
|
|
|
the Python comment
|
|
|
|
|
``'Field renamed because it was a Python reserved word.'`` next to the
|
|
|
|
|
field.
|
2006-02-04 20:08:30 +00:00
|
|
|
|
|
2005-08-10 20:24:51 +00:00
|
|
|
|
This feature is meant as a shortcut, not as definitive model generation. After
|
|
|
|
|
you run it, you'll want to look over the generated models yourself to make
|
2006-02-18 21:26:28 +00:00
|
|
|
|
customizations. In particular, you'll need to rearrange models' order, so that
|
|
|
|
|
models that refer to other models are ordered properly.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2006-07-07 04:06:00 +00:00
|
|
|
|
Primary keys are automatically introspected for PostgreSQL, MySQL and
|
|
|
|
|
SQLite, in which case Django puts in the ``primary_key=True`` where
|
|
|
|
|
needed.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2005-11-29 02:05:32 +00:00
|
|
|
|
``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection
|
2006-05-02 01:31:56 +00:00
|
|
|
|
only works in PostgreSQL and with certain types of MySQL tables.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2014-08-19 10:14:14 +00:00
|
|
|
|
Django doesn't create database defaults when a
|
|
|
|
|
:attr:`~django.db.models.Field.default` is specified on a model field.
|
|
|
|
|
Similarly, database defaults aren't translated to model field defaults or
|
|
|
|
|
detected in any fashion by ``inspectdb``.
|
|
|
|
|
|
2014-03-25 14:17:23 +00:00
|
|
|
|
By default, ``inspectdb`` creates unmanaged models. That is, ``managed = False``
|
|
|
|
|
in the model's ``Meta`` class tells Django not to manage each table's creation,
|
|
|
|
|
modification, and deletion. If you do want to allow Django to manage the
|
|
|
|
|
table's lifecycle, you'll need to change the
|
|
|
|
|
:attr:`~django.db.models.Options.managed` option to ``True`` (or simply remove
|
|
|
|
|
it because ``True`` is its default value).
|
2013-02-03 00:08:45 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--database` option may be used to specify the
|
|
|
|
|
database to introspect.
|
|
|
|
|
|
2007-09-09 21:57:59 +00:00
|
|
|
|
loaddata <fixture fixture ...>
|
2007-03-01 13:11:08 +00:00
|
|
|
|
------------------------------
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: loaddata
|
|
|
|
|
|
2007-03-01 13:11:08 +00:00
|
|
|
|
Searches for and loads the contents of the named fixture into the database.
|
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--database` option can be used to specify the database
|
|
|
|
|
onto which the data will be loaded.
|
|
|
|
|
|
2013-01-01 13:12:42 +00:00
|
|
|
|
.. django-admin-option:: --ignorenonexistent
|
|
|
|
|
|
2014-02-21 06:43:08 +00:00
|
|
|
|
The :djadminopt:`--ignorenonexistent` option can be used to ignore fields and
|
|
|
|
|
models that may have been removed since the fixture was originally generated.
|
2014-02-09 12:22:29 +00:00
|
|
|
|
|
2014-12-19 04:52:01 +00:00
|
|
|
|
.. django-admin-option:: --app
|
|
|
|
|
|
|
|
|
|
The :djadminopt:`--app` option can be used to specify a single app to look
|
|
|
|
|
for fixtures in rather than looking through all apps.
|
|
|
|
|
|
2014-02-21 06:43:08 +00:00
|
|
|
|
.. versionchanged:: 1.8
|
|
|
|
|
|
|
|
|
|
``--ignorenonexistent`` also ignores non-existent models.
|
|
|
|
|
|
2008-11-24 20:42:09 +00:00
|
|
|
|
What's a "fixture"?
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2007-09-09 21:57:59 +00:00
|
|
|
|
A *fixture* is a collection of files that contain the serialized contents of
|
|
|
|
|
the database. Each fixture has a unique name, and the files that comprise the
|
|
|
|
|
fixture can be distributed over multiple directories, in multiple applications.
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
|
|
|
|
Django will search in three locations for fixtures:
|
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
1. In the ``fixtures`` directory of every installed application
|
|
|
|
|
2. In any directory named in the :setting:`FIXTURE_DIRS` setting
|
|
|
|
|
3. In the literal path named by the fixture
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
|
|
|
|
Django will load any and all fixtures it finds in these locations that match
|
2007-04-09 01:44:26 +00:00
|
|
|
|
the provided fixture names.
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
2007-04-09 01:44:26 +00:00
|
|
|
|
If the named fixture has a file extension, only fixtures of that type
|
2007-03-01 13:11:08 +00:00
|
|
|
|
will be loaded. For example::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin loaddata mydata.json
|
2007-04-09 01:44:26 +00:00
|
|
|
|
|
|
|
|
|
would only load JSON fixtures called ``mydata``. The fixture extension
|
2008-11-24 20:42:09 +00:00
|
|
|
|
must correspond to the registered name of a
|
|
|
|
|
:ref:`serializer <serialization-formats>` (e.g., ``json`` or ``xml``).
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
2008-11-24 20:42:09 +00:00
|
|
|
|
If you omit the extensions, Django will search all available fixture types
|
2007-03-01 13:11:08 +00:00
|
|
|
|
for a matching fixture. For example::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin loaddata mydata
|
2007-04-09 01:44:26 +00:00
|
|
|
|
|
2007-03-01 13:11:08 +00:00
|
|
|
|
would look for any fixture of any fixture type called ``mydata``. If a fixture
|
|
|
|
|
directory contained ``mydata.json``, that fixture would be loaded
|
2008-11-24 20:42:09 +00:00
|
|
|
|
as a JSON fixture.
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
2007-04-09 01:44:26 +00:00
|
|
|
|
The fixtures that are named can include directory components. These
|
2007-03-16 15:02:21 +00:00
|
|
|
|
directories will be included in the search path. For example::
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin loaddata foo/bar/mydata.json
|
2007-04-09 01:44:26 +00:00
|
|
|
|
|
2013-12-28 08:53:02 +00:00
|
|
|
|
would search ``<app_label>/fixtures/foo/bar/mydata.json`` for each installed
|
2007-04-09 01:44:26 +00:00
|
|
|
|
application, ``<dirname>/foo/bar/mydata.json`` for each directory in
|
2011-05-29 17:41:04 +00:00
|
|
|
|
:setting:`FIXTURE_DIRS`, and the literal path ``foo/bar/mydata.json``.
|
2007-03-01 13:11:08 +00:00
|
|
|
|
|
2009-03-31 23:34:03 +00:00
|
|
|
|
When fixture files are processed, the data is saved to the database as is.
|
2013-05-11 23:34:02 +00:00
|
|
|
|
Model defined :meth:`~django.db.models.Model.save` methods are not called, and
|
|
|
|
|
any :data:`~django.db.models.signals.pre_save` or
|
|
|
|
|
:data:`~django.db.models.signals.post_save` signals will be called with
|
|
|
|
|
``raw=True`` since the instance only contains attributes that are local to the
|
|
|
|
|
model. You may, for example, want to disable handlers that access
|
|
|
|
|
related fields that aren't present during fixture loading and would otherwise
|
|
|
|
|
raise an exception::
|
|
|
|
|
|
|
|
|
|
from django.db.models.signals import post_save
|
|
|
|
|
from .models import MyModel
|
|
|
|
|
|
|
|
|
|
def my_handler(**kwargs):
|
|
|
|
|
# disable the handler during fixture loading
|
|
|
|
|
if kwargs['raw']:
|
|
|
|
|
return
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
post_save.connect(my_handler, sender=MyModel)
|
|
|
|
|
|
|
|
|
|
You could also write a simple decorator to encapsulate this logic::
|
|
|
|
|
|
|
|
|
|
from functools import wraps
|
|
|
|
|
|
|
|
|
|
def disable_for_loaddata(signal_handler):
|
|
|
|
|
"""
|
|
|
|
|
Decorator that turns off signal handlers when loading fixture data.
|
|
|
|
|
"""
|
|
|
|
|
@wraps(signal_handler)
|
|
|
|
|
def wrapper(*args, **kwargs):
|
|
|
|
|
if kwargs['raw']:
|
|
|
|
|
return
|
|
|
|
|
signal_handler(*args, **kwargs)
|
|
|
|
|
return wrapper
|
|
|
|
|
|
|
|
|
|
@disable_for_loaddata
|
|
|
|
|
def my_handler(**kwargs):
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
Just be aware that this logic will disable the signals whenever fixtures are
|
|
|
|
|
deserialized, not just during ``loaddata``.
|
2009-03-31 23:34:03 +00:00
|
|
|
|
|
2007-03-01 13:11:08 +00:00
|
|
|
|
Note that the order in which fixture files are processed is undefined. However,
|
|
|
|
|
all fixture data is installed as a single transaction, so data in
|
|
|
|
|
one fixture can reference data in another fixture. If the database backend
|
|
|
|
|
supports row-level constraints, these constraints will be checked at the
|
|
|
|
|
end of the transaction.
|
|
|
|
|
|
2013-11-18 18:25:28 +00:00
|
|
|
|
The :djadmin:`dumpdata` command can be used to generate input for ``loaddata``.
|
2007-04-09 12:11:19 +00:00
|
|
|
|
|
2008-11-24 20:42:09 +00:00
|
|
|
|
Compressed fixtures
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Fixtures may be compressed in ``zip``, ``gz``, or ``bz2`` format. For example::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin loaddata mydata.json
|
2008-11-24 20:42:09 +00:00
|
|
|
|
|
|
|
|
|
would look for any of ``mydata.json``, ``mydata.json.zip``,
|
2012-02-03 17:52:39 +00:00
|
|
|
|
``mydata.json.gz``, or ``mydata.json.bz2``. The first file contained within a
|
2008-11-24 20:42:09 +00:00
|
|
|
|
zip-compressed archive is used.
|
|
|
|
|
|
|
|
|
|
Note that if two fixtures with the same name but different
|
|
|
|
|
fixture type are discovered (for example, if ``mydata.json`` and
|
|
|
|
|
``mydata.xml.gz`` were found in the same fixture directory), fixture
|
|
|
|
|
installation will be aborted, and any data installed in the call to
|
|
|
|
|
``loaddata`` will be removed from the database.
|
|
|
|
|
|
2012-02-19 07:39:05 +00:00
|
|
|
|
.. admonition:: MySQL with MyISAM and fixtures
|
|
|
|
|
|
|
|
|
|
The MyISAM storage engine of MySQL doesn't support transactions or
|
2012-03-02 17:16:52 +00:00
|
|
|
|
constraints, so if you use MyISAM, you won't get validation of fixture
|
|
|
|
|
data, or a rollback if multiple transaction files are found.
|
2007-04-09 01:44:26 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
Database-specific fixtures
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2011-04-20 16:28:02 +00:00
|
|
|
|
If you're in a multi-database setup, you might have fixture data that
|
2009-12-22 15:18:51 +00:00
|
|
|
|
you want to load onto one database, but not onto another. In this
|
2015-05-07 23:41:42 +00:00
|
|
|
|
situation, you can add a database identifier into the names of your fixtures.
|
2011-04-20 16:28:02 +00:00
|
|
|
|
|
|
|
|
|
For example, if your :setting:`DATABASES` setting has a 'master' database
|
|
|
|
|
defined, name the fixture ``mydata.master.json`` or
|
|
|
|
|
``mydata.master.json.gz`` and the fixture will only be loaded when you
|
|
|
|
|
specify you want to load data into the ``master`` database.
|
2009-12-22 15:18:51 +00:00
|
|
|
|
|
2008-07-06 06:39:44 +00:00
|
|
|
|
makemessages
|
|
|
|
|
------------
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: makemessages
|
|
|
|
|
|
2008-07-06 06:39:44 +00:00
|
|
|
|
Runs over the entire source tree of the current directory and pulls out all
|
|
|
|
|
strings marked for translation. It creates (or updates) a message file in the
|
2013-11-02 19:13:36 +00:00
|
|
|
|
conf/locale (in the Django tree) or locale (for project and application)
|
2008-07-06 06:39:44 +00:00
|
|
|
|
directory. After making changes to the messages files you need to compile them
|
2013-11-18 18:25:28 +00:00
|
|
|
|
with :djadmin:`compilemessages` for use with the builtin gettext support. See
|
|
|
|
|
the :ref:`i18n documentation <how-to-create-language-files>` for details.
|
2008-07-06 06:39:44 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --all
|
2008-07-06 06:39:44 +00:00
|
|
|
|
|
|
|
|
|
Use the ``--all`` or ``-a`` option to update the message files for all
|
|
|
|
|
available languages.
|
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin makemessages --all
|
2008-07-06 06:39:44 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --extension
|
2008-08-08 16:41:55 +00:00
|
|
|
|
|
|
|
|
|
Use the ``--extension`` or ``-e`` option to specify a list of file extensions
|
2011-06-19 11:24:25 +00:00
|
|
|
|
to examine (default: ".html", ".txt").
|
2008-08-08 16:41:55 +00:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin makemessages --locale=de --extension xhtml
|
2008-08-08 16:41:55 +00:00
|
|
|
|
|
|
|
|
|
Separate multiple extensions with commas or use -e or --extension multiple times::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin makemessages --locale=de --extension=html,txt --extension xml
|
2008-08-08 16:41:55 +00:00
|
|
|
|
|
2012-06-07 09:23:25 +00:00
|
|
|
|
Use the :djadminopt:`--locale` option (or its shorter version ``-l``) to
|
|
|
|
|
specify the locale(s) to process.
|
2008-07-06 06:39:44 +00:00
|
|
|
|
|
2014-03-24 13:03:06 +00:00
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
2014-05-01 07:03:24 +00:00
|
|
|
|
Use the :djadminopt:`--exclude` option (or its shorter version ``-x``) to
|
2014-03-24 13:03:06 +00:00
|
|
|
|
specify the locale(s) to exclude from processing. If not provided, no locales
|
|
|
|
|
are excluded.
|
|
|
|
|
|
2008-07-06 06:39:44 +00:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin makemessages --locale=pt_BR
|
|
|
|
|
django-admin makemessages --locale=pt_BR --locale=fr
|
|
|
|
|
django-admin makemessages -l pt_BR
|
|
|
|
|
django-admin makemessages -l pt_BR -l fr
|
|
|
|
|
django-admin makemessages --exclude=pt_BR
|
|
|
|
|
django-admin makemessages --exclude=pt_BR --exclude=fr
|
|
|
|
|
django-admin makemessages -x pt_BR
|
|
|
|
|
django-admin makemessages -x pt_BR -x fr
|
2014-03-24 13:03:06 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --domain
|
2008-07-06 06:39:44 +00:00
|
|
|
|
|
|
|
|
|
Use the ``--domain`` or ``-d`` option to change the domain of the messages files.
|
|
|
|
|
Currently supported:
|
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``django`` for all ``*.py``, ``*.html`` and ``*.txt`` files (default)
|
|
|
|
|
* ``djangojs`` for ``*.js`` files
|
2010-02-16 12:14:27 +00:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --symlinks
|
|
|
|
|
|
|
|
|
|
Use the ``--symlinks`` or ``-s`` option to follow symlinks to directories when
|
|
|
|
|
looking for new translation strings.
|
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin makemessages --locale=de --symlinks
|
2008-07-06 06:39:44 +00:00
|
|
|
|
|
2010-02-16 12:15:04 +00:00
|
|
|
|
.. django-admin-option:: --ignore
|
|
|
|
|
|
|
|
|
|
Use the ``--ignore`` or ``-i`` option to ignore files or directories matching
|
2011-09-04 21:17:30 +00:00
|
|
|
|
the given :mod:`glob`-style pattern. Use multiple times to ignore more.
|
2010-02-16 12:15:04 +00:00
|
|
|
|
|
2013-11-30 09:53:08 +00:00
|
|
|
|
These patterns are used by default: ``'CVS'``, ``'.*'``, ``'*~'``, ``'*.pyc'``
|
2010-02-16 12:15:04 +00:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
|
2010-02-16 12:15:04 +00:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --no-default-ignore
|
|
|
|
|
|
|
|
|
|
Use the ``--no-default-ignore`` option to disable the default values of
|
|
|
|
|
:djadminopt:`--ignore`.
|
|
|
|
|
|
2010-11-04 12:08:37 +00:00
|
|
|
|
.. django-admin-option:: --no-wrap
|
|
|
|
|
|
|
|
|
|
Use the ``--no-wrap`` option to disable breaking long message lines into
|
|
|
|
|
several lines in language files.
|
|
|
|
|
|
2011-11-11 13:07:14 +00:00
|
|
|
|
.. django-admin-option:: --no-location
|
|
|
|
|
|
2015-05-07 23:41:42 +00:00
|
|
|
|
Use the ``--no-location`` option to suppress writing '``#: filename:line``’
|
2011-11-11 13:07:14 +00:00
|
|
|
|
comment lines in language files. Note that using this option makes it harder
|
|
|
|
|
for technically skilled translators to understand each message's context.
|
|
|
|
|
|
2013-01-16 18:36:22 +00:00
|
|
|
|
.. django-admin-option:: --keep-pot
|
|
|
|
|
|
2013-11-02 19:13:36 +00:00
|
|
|
|
Use the ``--keep-pot`` option to prevent Django from deleting the temporary
|
2013-11-30 09:53:08 +00:00
|
|
|
|
.pot files it generates before creating the .po file. This is useful for
|
2013-01-16 18:36:22 +00:00
|
|
|
|
debugging errors which may prevent the final language files from being created.
|
|
|
|
|
|
2014-10-29 14:38:46 +00:00
|
|
|
|
.. seealso::
|
|
|
|
|
|
|
|
|
|
See :ref:`customizing-makemessages` for instructions on how to customize
|
|
|
|
|
the keywords that :djadmin:`makemessages` passes to ``xgettext``.
|
|
|
|
|
|
2013-12-28 08:53:02 +00:00
|
|
|
|
makemigrations [<app_label>]
|
|
|
|
|
----------------------------
|
2013-07-25 13:45:38 +00:00
|
|
|
|
|
|
|
|
|
.. django-admin:: makemigrations
|
|
|
|
|
|
|
|
|
|
Creates new migrations based on the changes detected to your models.
|
|
|
|
|
Migrations, their relationship with apps and more are covered in depth in
|
|
|
|
|
:doc:`the migrations documentation</topics/migrations>`.
|
|
|
|
|
|
|
|
|
|
Providing one or more app names as arguments will limit the migrations created
|
2013-08-10 19:00:12 +00:00
|
|
|
|
to the app(s) specified and any dependencies needed (the table at the other end
|
|
|
|
|
of a ``ForeignKey``, for example).
|
2013-07-25 13:45:38 +00:00
|
|
|
|
|
2015-03-07 12:53:13 +00:00
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
The ``--noinput`` option may be provided to suppress all user prompts. If a suppressed
|
|
|
|
|
prompt cannot be resolved automatically, the command will exit with error code 3.
|
|
|
|
|
|
2013-07-25 13:45:38 +00:00
|
|
|
|
.. django-admin-option:: --empty
|
|
|
|
|
|
|
|
|
|
The ``--empty`` option will cause ``makemigrations`` to output an empty
|
|
|
|
|
migration for the specified apps, for manual editing. This option is only
|
|
|
|
|
for advanced users and should not be used unless you are familiar with
|
2013-08-10 19:00:12 +00:00
|
|
|
|
the migration format, migration operations, and the dependencies between
|
2013-07-25 13:45:38 +00:00
|
|
|
|
your migrations.
|
|
|
|
|
|
2014-05-24 17:31:34 +00:00
|
|
|
|
.. django-admin-option:: --dry-run
|
|
|
|
|
|
|
|
|
|
The ``--dry-run`` option shows what migrations would be made without
|
2014-05-26 20:09:17 +00:00
|
|
|
|
actually writing any migrations files to disk. Using this option along with
|
|
|
|
|
``--verbosity 3`` will also show the complete migrations files that would be
|
|
|
|
|
written.
|
2014-05-24 17:31:34 +00:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --merge
|
|
|
|
|
|
2015-03-07 12:53:13 +00:00
|
|
|
|
The ``--merge`` option enables fixing of migration conflicts.
|
2014-05-24 17:31:34 +00:00
|
|
|
|
|
2014-08-19 13:24:31 +00:00
|
|
|
|
.. django-admin-option:: --name, -n
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
The ``--name`` option allows you to give the migration(s) a custom name instead
|
|
|
|
|
of a generated one.
|
|
|
|
|
|
2014-11-11 04:41:55 +00:00
|
|
|
|
.. django-admin-option:: --exit, -e
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
The ``--exit`` option will cause ``makemigrations`` to exit with error code 1
|
2015-05-07 23:41:42 +00:00
|
|
|
|
when no migrations are created (or would have been created, if combined with
|
2014-11-11 04:41:55 +00:00
|
|
|
|
``--dry-run``).
|
|
|
|
|
|
2013-12-28 08:53:02 +00:00
|
|
|
|
migrate [<app_label> [<migrationname>]]
|
|
|
|
|
---------------------------------------
|
2013-07-25 13:45:38 +00:00
|
|
|
|
|
|
|
|
|
.. django-admin:: migrate
|
|
|
|
|
|
2013-08-10 19:00:12 +00:00
|
|
|
|
Synchronizes the database state with the current set of models and migrations.
|
2013-07-25 13:45:38 +00:00
|
|
|
|
Migrations, their relationship with apps and more are covered in depth in
|
|
|
|
|
:doc:`the migrations documentation</topics/migrations>`.
|
|
|
|
|
|
2013-08-10 19:00:12 +00:00
|
|
|
|
The behavior of this command changes depending on the arguments provided:
|
2013-07-25 13:45:38 +00:00
|
|
|
|
|
2015-02-09 15:28:42 +00:00
|
|
|
|
* No arguments: All apps have all of their migrations run.
|
2013-12-28 08:53:02 +00:00
|
|
|
|
* ``<app_label>``: The specified app has its migrations run, up to the most
|
2013-07-25 13:45:38 +00:00
|
|
|
|
recent migration. This may involve running other apps' migrations too, due
|
|
|
|
|
to dependencies.
|
2014-11-17 17:13:47 +00:00
|
|
|
|
* ``<app_label> <migrationname>``: Brings the database schema to a state where
|
|
|
|
|
the named migration is applied, but no later migrations in the same app are
|
|
|
|
|
applied. This may involve unapplying migrations if you have previously
|
|
|
|
|
migrated past the named migration. Use the name ``zero`` to unapply all
|
|
|
|
|
migrations for an app.
|
2014-07-06 07:30:05 +00:00
|
|
|
|
|
2014-08-27 12:01:30 +00:00
|
|
|
|
The :djadminopt:`--database` option can be used to specify the database to
|
|
|
|
|
migrate.
|
|
|
|
|
|
2014-07-06 07:30:05 +00:00
|
|
|
|
.. django-admin-option:: --fake
|
|
|
|
|
|
|
|
|
|
The ``--fake`` option tells Django to mark the migrations as having been
|
|
|
|
|
applied or unapplied, but without actually running the SQL to change your
|
|
|
|
|
database schema.
|
|
|
|
|
|
|
|
|
|
This is intended for advanced users to manipulate the
|
|
|
|
|
current migration state directly if they're manually applying changes;
|
|
|
|
|
be warned that using ``--fake`` runs the risk of putting the migration state
|
|
|
|
|
table into a state where manual recovery will be needed to make migrations
|
|
|
|
|
run correctly.
|
|
|
|
|
|
2015-02-12 11:48:28 +00:00
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --fake-initial
|
|
|
|
|
|
|
|
|
|
The ``--fake-initial`` option can be used to allow Django to skip an app's
|
|
|
|
|
initial migration if all database tables with the names of all models created
|
|
|
|
|
by all :class:`~django.db.migrations.operations.CreateModel` operations in that
|
|
|
|
|
migration already exist. This option is intended for use when first running
|
|
|
|
|
migrations against a database that preexisted the use of migrations. This
|
|
|
|
|
option does not, however, check for matching database schema beyond matching
|
|
|
|
|
table names and so is only safe to use if you are confident that your existing
|
|
|
|
|
schema matches what is recorded in your initial migration.
|
|
|
|
|
|
2014-09-03 08:51:07 +00:00
|
|
|
|
.. deprecated:: 1.8
|
2014-07-06 07:30:05 +00:00
|
|
|
|
|
2014-09-03 08:51:07 +00:00
|
|
|
|
The ``--list`` option has been moved to the :djadmin:`showmigrations`
|
|
|
|
|
command.
|
2013-07-25 13:45:38 +00:00
|
|
|
|
|
2011-01-15 06:31:38 +00:00
|
|
|
|
runserver [port or address:port]
|
2011-01-15 18:45:49 +00:00
|
|
|
|
--------------------------------
|
Fixed a whole bunch of small docs typos, errors, and ommissions.
Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.
Thanks to all the respective authors of those tickets.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10371 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-04-03 18:30:54 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: runserver
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
|
|
|
|
Starts a lightweight development Web server on the local machine. By default,
|
2010-11-26 13:33:53 +00:00
|
|
|
|
the server runs on port 8000 on the IP address ``127.0.0.1``. You can pass in an
|
2005-08-19 21:23:56 +00:00
|
|
|
|
IP address and port number explicitly.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
|
|
|
|
If you run this script as a user with normal privileges (recommended), you
|
|
|
|
|
might not have access to start a port on a low port number. Low port numbers
|
2006-05-02 01:31:56 +00:00
|
|
|
|
are reserved for the superuser (root).
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2012-12-26 20:47:29 +00:00
|
|
|
|
This server uses the WSGI application object specified by the
|
|
|
|
|
:setting:`WSGI_APPLICATION` setting.
|
2011-10-22 04:30:10 +00:00
|
|
|
|
|
2006-06-02 05:40:31 +00:00
|
|
|
|
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
|
|
|
|
|
security audits or performance tests. (And that's how it's gonna stay. We're in
|
|
|
|
|
the business of making Web frameworks, not Web servers, so improving this
|
|
|
|
|
server to be able to handle a production environment is outside the scope of
|
|
|
|
|
Django.)
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
|
|
|
|
The development server automatically reloads Python code for each request, as
|
|
|
|
|
needed. You don't need to restart the server for code changes to take effect.
|
2013-11-02 19:13:36 +00:00
|
|
|
|
However, some actions like adding files don't trigger a restart, so you'll
|
2013-11-02 09:28:22 +00:00
|
|
|
|
have to restart the server in these cases.
|
|
|
|
|
|
2013-10-14 05:33:45 +00:00
|
|
|
|
If you are using Linux and install `pyinotify`_, kernel signals will be used to
|
|
|
|
|
autoreload the server (rather than polling file modification timestamps each
|
|
|
|
|
second). This offers better scaling to large projects, reduction in response
|
|
|
|
|
time to code modification, more robust change detection, and battery usage
|
|
|
|
|
reduction.
|
|
|
|
|
|
|
|
|
|
.. _pyinotify: https://pypi.python.org/pypi/pyinotify/
|
|
|
|
|
|
2005-08-18 04:50:09 +00:00
|
|
|
|
When you start the server, and each time you change Python code while the
|
2015-04-25 19:05:48 +00:00
|
|
|
|
server is running, the system check framework will check your entire Django
|
|
|
|
|
project for some common errors (see the :djadmin:`check` command). If any
|
|
|
|
|
errors are found, they will be printed to standard output.
|
2005-08-18 04:50:09 +00:00
|
|
|
|
|
2015-05-07 23:41:42 +00:00
|
|
|
|
You can run as many concurrent servers as you want, as long as they're on
|
|
|
|
|
separate ports. Just execute ``django-admin runserver`` more than once.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2010-11-26 13:33:53 +00:00
|
|
|
|
Note that the default IP address, ``127.0.0.1``, is not accessible from other
|
2005-10-17 13:05:55 +00:00
|
|
|
|
machines on your network. To make your development server viewable to other
|
|
|
|
|
machines on the network, use its own IP address (e.g. ``192.168.2.1``) or
|
2010-11-26 13:33:53 +00:00
|
|
|
|
``0.0.0.0`` or ``::`` (with IPv6 enabled).
|
|
|
|
|
|
2011-01-15 06:31:38 +00:00
|
|
|
|
You can provide an IPv6 address surrounded by brackets
|
|
|
|
|
(e.g. ``[200a::1]:8000``). This will automatically enable IPv6 support.
|
|
|
|
|
|
|
|
|
|
A hostname containing ASCII-only characters can also be used.
|
2005-10-17 13:05:55 +00:00
|
|
|
|
|
2011-01-30 17:23:30 +00:00
|
|
|
|
If the :doc:`staticfiles</ref/contrib/staticfiles>` contrib app is enabled
|
2013-07-28 01:45:25 +00:00
|
|
|
|
(default in new projects) the :djadmin:`runserver` command will be overridden
|
2012-09-28 00:25:31 +00:00
|
|
|
|
with its own :ref:`runserver<staticfiles-runserver>` command.
|
2011-01-30 17:23:30 +00:00
|
|
|
|
|
2014-11-24 13:32:07 +00:00
|
|
|
|
If :djadmin:`migrate` was not previously executed, the table that stores the
|
2014-11-15 10:53:36 +00:00
|
|
|
|
history of migrations is created at first run of ``runserver``.
|
|
|
|
|
|
Fixed a whole bunch of small docs typos, errors, and ommissions.
Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.
Thanks to all the respective authors of those tickets.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10371 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-04-03 18:30:54 +00:00
|
|
|
|
.. django-admin-option:: --noreload
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
|
|
|
|
Use the ``--noreload`` option to disable the use of the auto-reloader. This
|
|
|
|
|
means any Python code changes you make while the server is running will *not*
|
|
|
|
|
take effect if the particular Python modules have already been loaded into
|
|
|
|
|
memory.
|
|
|
|
|
|
2008-06-16 03:37:57 +00:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver --noreload
|
2008-06-16 03:37:57 +00:00
|
|
|
|
|
2011-06-17 13:08:36 +00:00
|
|
|
|
.. django-admin-option:: --nothreading
|
|
|
|
|
|
2012-12-26 20:47:29 +00:00
|
|
|
|
The development server is multithreaded by default. Use the ``--nothreading``
|
|
|
|
|
option to disable the use of threading in the development server.
|
2011-06-17 13:08:36 +00:00
|
|
|
|
|
2010-11-26 13:33:53 +00:00
|
|
|
|
.. django-admin-option:: --ipv6, -6
|
|
|
|
|
|
|
|
|
|
Use the ``--ipv6`` (or shorter ``-6``) option to tell Django to use IPv6 for
|
|
|
|
|
the development server. This changes the default IP address from
|
|
|
|
|
``127.0.0.1`` to ``::1``.
|
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver --ipv6
|
2010-11-26 13:33:53 +00:00
|
|
|
|
|
2007-09-09 22:00:30 +00:00
|
|
|
|
Examples of using different ports and addresses
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2010-11-26 13:33:53 +00:00
|
|
|
|
Port 8000 on IP address ``127.0.0.1``::
|
2007-09-09 22:00:30 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver
|
2007-09-09 22:00:30 +00:00
|
|
|
|
|
2010-11-26 13:33:53 +00:00
|
|
|
|
Port 8000 on IP address ``1.2.3.4``::
|
2007-09-09 22:00:30 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver 1.2.3.4:8000
|
2005-08-19 21:23:56 +00:00
|
|
|
|
|
2010-11-26 13:33:53 +00:00
|
|
|
|
Port 7000 on IP address ``127.0.0.1``::
|
2005-08-19 21:23:56 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver 7000
|
2005-08-19 21:23:56 +00:00
|
|
|
|
|
2010-11-26 13:33:53 +00:00
|
|
|
|
Port 7000 on IP address ``1.2.3.4``::
|
2005-08-19 21:23:56 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver 1.2.3.4:7000
|
2005-08-19 21:23:56 +00:00
|
|
|
|
|
2010-11-26 13:33:53 +00:00
|
|
|
|
Port 8000 on IPv6 address ``::1``::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver -6
|
2010-11-26 13:33:53 +00:00
|
|
|
|
|
|
|
|
|
Port 7000 on IPv6 address ``::1``::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver -6 7000
|
2010-11-26 13:33:53 +00:00
|
|
|
|
|
|
|
|
|
Port 7000 on IPv6 address ``2001:0db8:1234:5678::9``::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver [2001:0db8:1234:5678::9]:7000
|
2010-11-26 13:33:53 +00:00
|
|
|
|
|
2011-01-15 06:31:38 +00:00
|
|
|
|
Port 8000 on IPv4 address of host ``localhost``::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver localhost:8000
|
2011-01-15 06:31:38 +00:00
|
|
|
|
|
|
|
|
|
Port 8000 on IPv6 address of host ``localhost``::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin runserver -6 localhost:8000
|
2011-01-15 06:31:38 +00:00
|
|
|
|
|
2006-05-19 05:07:33 +00:00
|
|
|
|
Serving static files with the development server
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2006-05-19 03:47:59 +00:00
|
|
|
|
|
2006-05-19 05:07:33 +00:00
|
|
|
|
By default, the development server doesn't serve any static files for your site
|
2011-05-29 17:41:04 +00:00
|
|
|
|
(such as CSS files, images, things under :setting:`MEDIA_URL` and so forth). If
|
2013-03-07 19:15:39 +00:00
|
|
|
|
you want to configure Django to serve static media, read
|
|
|
|
|
:doc:`/howto/static-files/index`.
|
2008-08-23 22:25:40 +00:00
|
|
|
|
|
2015-03-07 12:55:59 +00:00
|
|
|
|
sendtestemail
|
|
|
|
|
-------------
|
|
|
|
|
|
|
|
|
|
.. django-admin:: sendtestemail
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.9
|
|
|
|
|
|
|
|
|
|
Sends a test email (to confirm email sending through Django is working) to the
|
|
|
|
|
recipient(s) specified. For example::
|
|
|
|
|
|
|
|
|
|
django-admin sendtestemail foo@example.com bar@example.com
|
|
|
|
|
|
2015-06-16 12:46:56 +00:00
|
|
|
|
.. django-admin-option:: --managers
|
|
|
|
|
|
|
|
|
|
Use the ``--managers`` option to mail the email addresses specified in
|
|
|
|
|
:setting:`MANAGERS` using :meth:`~django.core.mail.mail_managers()`.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --admins
|
|
|
|
|
|
|
|
|
|
Use the ``--admins`` option to mail the email addresses specified in
|
|
|
|
|
:setting:`ADMINS` using :meth:`~django.core.mail.mail_admins()`.
|
|
|
|
|
|
|
|
|
|
Note that you may use any combination of these options together.
|
|
|
|
|
|
2006-01-12 20:56:10 +00:00
|
|
|
|
shell
|
|
|
|
|
-----
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: shell
|
|
|
|
|
|
2006-01-12 20:56:10 +00:00
|
|
|
|
Starts the Python interactive interpreter.
|
|
|
|
|
|
2010-12-12 23:03:24 +00:00
|
|
|
|
Django will use IPython_ or bpython_ if either is installed. If you have a
|
|
|
|
|
rich shell installed but want to force use of the "plain" Python interpreter,
|
|
|
|
|
use the ``--plain`` option, like so::
|
2006-01-12 20:56:10 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin shell --plain
|
2006-01-12 20:56:10 +00:00
|
|
|
|
|
2012-07-17 00:37:52 +00:00
|
|
|
|
If you would like to specify either IPython or bpython as your interpreter if
|
|
|
|
|
you have both installed you can specify an alternative interpreter interface
|
2012-08-05 20:47:29 +00:00
|
|
|
|
with the ``-i`` or ``--interface`` options like so:
|
2012-07-17 00:37:52 +00:00
|
|
|
|
|
|
|
|
|
IPython::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin shell -i ipython
|
|
|
|
|
django-admin shell --interface ipython
|
2012-07-17 00:37:52 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bpython::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin shell -i bpython
|
|
|
|
|
django-admin shell --interface bpython
|
2012-07-17 00:37:52 +00:00
|
|
|
|
|
|
|
|
|
|
2006-01-12 20:56:10 +00:00
|
|
|
|
.. _IPython: http://ipython.scipy.org/
|
2010-12-12 23:03:24 +00:00
|
|
|
|
.. _bpython: http://bpython-interpreter.org/
|
2006-01-12 20:56:10 +00:00
|
|
|
|
|
2013-01-25 00:21:26 +00:00
|
|
|
|
When the "plain" Python interactive interpreter starts (be it because
|
|
|
|
|
``--plain`` was specified or because no other interactive interface is
|
|
|
|
|
available) it reads the script pointed to by the :envvar:`PYTHONSTARTUP`
|
|
|
|
|
environment variable and the ``~/.pythonrc.py`` script. If you don't wish this
|
|
|
|
|
behavior you can use the ``--no-startup`` option. e.g.::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin shell --plain --no-startup
|
2013-01-25 00:21:26 +00:00
|
|
|
|
|
2014-09-03 08:51:07 +00:00
|
|
|
|
showmigrations [<app_label> [<app_label>]]
|
|
|
|
|
------------------------------------------
|
|
|
|
|
|
|
|
|
|
.. django-admin:: showmigrations
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
Shows all migrations in a project.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --list, -l
|
|
|
|
|
|
|
|
|
|
The ``--list`` option lists all of the apps Django knows about, the
|
2015-05-07 23:41:42 +00:00
|
|
|
|
migrations available for each app, and whether or not each migration is
|
2014-09-03 08:51:07 +00:00
|
|
|
|
applied (marked by an ``[X]`` next to the migration name).
|
|
|
|
|
|
|
|
|
|
Apps without migrations are also listed, but have ``(no migrations)`` printed
|
|
|
|
|
under them.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --plan, -p
|
|
|
|
|
|
|
|
|
|
The ``--plan`` option shows the migration plan Django will follow to apply
|
|
|
|
|
migrations. Any supplied app labels are ignored because the plan might go
|
|
|
|
|
beyond those apps. Same as ``--list``, applied migrations are marked by an
|
|
|
|
|
``[X]``. For a verbosity of 2 and above, all dependencies of a migration will
|
|
|
|
|
also be shown.
|
|
|
|
|
|
2007-08-25 19:32:30 +00:00
|
|
|
|
sqlflush
|
|
|
|
|
--------
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: sqlflush
|
|
|
|
|
|
|
|
|
|
Prints the SQL statements that would be executed for the :djadmin:`flush`
|
|
|
|
|
command.
|
2007-08-25 19:32:30 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--database` option can be used to specify the database for
|
|
|
|
|
which to print the SQL.
|
|
|
|
|
|
2013-12-28 08:53:02 +00:00
|
|
|
|
sqlmigrate <app_label> <migrationname>
|
|
|
|
|
--------------------------------------
|
2013-09-06 20:27:51 +00:00
|
|
|
|
|
|
|
|
|
.. django-admin:: sqlmigrate
|
|
|
|
|
|
|
|
|
|
Prints the SQL for the named migration. This requires an active database
|
|
|
|
|
connection, which it will use to resolve constraint names; this means you must
|
|
|
|
|
generate the SQL against a copy of the database you wish to later apply it on.
|
|
|
|
|
|
2014-08-16 15:21:14 +00:00
|
|
|
|
Note that ``sqlmigrate`` doesn't colorize its output.
|
|
|
|
|
|
2013-09-06 20:27:51 +00:00
|
|
|
|
The :djadminopt:`--database` option can be used to specify the database for
|
|
|
|
|
which to generate the SQL.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --backwards
|
|
|
|
|
|
|
|
|
|
By default, the SQL created is for running the migration in the forwards
|
|
|
|
|
direction. Pass ``--backwards`` to generate the SQL for
|
2014-02-22 17:30:28 +00:00
|
|
|
|
unapplying the migration instead.
|
2013-09-06 20:27:51 +00:00
|
|
|
|
|
2015-03-29 14:59:35 +00:00
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
To increase the readability of the overall SQL output the SQL code
|
|
|
|
|
generated for each migration operation is preceded by the operation's
|
|
|
|
|
description.
|
|
|
|
|
|
2013-12-28 08:53:02 +00:00
|
|
|
|
sqlsequencereset <app_label app_label ...>
|
|
|
|
|
------------------------------------------
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: sqlsequencereset
|
|
|
|
|
|
2007-09-09 21:57:59 +00:00
|
|
|
|
Prints the SQL statements for resetting sequences for the given app name(s).
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2009-06-18 13:37:10 +00:00
|
|
|
|
Sequences are indexes used by some database engines to track the next available
|
|
|
|
|
number for automatically incremented fields.
|
|
|
|
|
|
|
|
|
|
Use this command to generate SQL which will fix cases where a sequence is out
|
|
|
|
|
of sync with its automatically incremented field data.
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
The :djadminopt:`--database` option can be used to specify the database for
|
|
|
|
|
which to print the SQL.
|
|
|
|
|
|
2014-04-14 17:07:02 +00:00
|
|
|
|
squashmigrations <app_label> <migration_name>
|
|
|
|
|
---------------------------------------------
|
|
|
|
|
|
|
|
|
|
.. django-admin:: squashmigrations
|
|
|
|
|
|
|
|
|
|
Squashes the migrations for ``app_label`` up to and including ``migration_name``
|
|
|
|
|
down into fewer migrations, if possible. The resulting squashed migrations
|
|
|
|
|
can live alongside the unsquashed ones safely. For more information,
|
|
|
|
|
please read :ref:`migration-squashing`.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --no-optimize
|
|
|
|
|
|
|
|
|
|
By default, Django will try to optimize the operations in your migrations
|
|
|
|
|
to reduce the size of the resulting file. Pass ``--no-optimize`` if this
|
|
|
|
|
process is failing for you or creating incorrect migrations, though please
|
2014-04-16 13:39:00 +00:00
|
|
|
|
also file a Django bug report about the behavior, as optimization is meant
|
2014-04-14 17:07:02 +00:00
|
|
|
|
to be safe.
|
|
|
|
|
|
|
|
|
|
|
2013-12-28 08:53:02 +00:00
|
|
|
|
startapp <app_label> [destination]
|
|
|
|
|
----------------------------------
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: startapp
|
|
|
|
|
|
2005-08-10 20:24:51 +00:00
|
|
|
|
Creates a Django app directory structure for the given app name in the current
|
2011-12-22 22:38:02 +00:00
|
|
|
|
directory or the given destination.
|
|
|
|
|
|
|
|
|
|
By default the directory created contains a ``models.py`` file and other app
|
2011-12-30 18:14:31 +00:00
|
|
|
|
template files. (See the `source`_ for more details.) If only the app
|
2011-12-22 22:38:02 +00:00
|
|
|
|
name is given, the app directory will be created in the current working
|
2005-08-10 20:24:51 +00:00
|
|
|
|
directory.
|
|
|
|
|
|
2012-01-04 23:55:34 +00:00
|
|
|
|
If the optional destination is provided, Django will use that existing
|
|
|
|
|
directory rather than creating a new one. You can use '.' to denote the current
|
|
|
|
|
working directory.
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2011-12-30 18:14:31 +00:00
|
|
|
|
For example::
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin startapp myapp /Users/jezdez/Code/myapp
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
Simplified default project template.
Squashed commit of:
commit 508ec9144b35c50794708225b496bde1eb5e60aa
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 22:50:55 2013 +0100
Tweaked default settings file.
* Explained why BASE_DIR exists.
* Added a link to the database configuration options, and put it in its
own section.
* Moved sensitive settings that must be changed for production at the
top.
commit 6515fd2f1aa73a86dc8dbd2ccf512ddb6b140d57
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 14:35:21 2013 +0100
Documented the simplified app & project templates in the changelog.
commit 2c5b576c2ea91d84273a019b3d0b3b8b4da72f23
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:59:27 2013 +0100
Minor fixes in tutorials 5 and 6.
commit 55a51531be8104f21b3cca3f6bf70b0a7139a041
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:51:11 2013 +0100
Updated tutorial 2 for the new project template.
commit 29ddae87bdaecff12dd31b16b000c01efbde9e20
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:58:54 2013 +0100
Updated tutorial 1 for the new project template.
commit 0ecb9f6e2514cfd26a678a280d471433375101a3
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:29:13 2013 +0100
Adjusted the default URLconf detection to account for the admin.
It's now enabled by default.
commit 5fb4da0d3d09dac28dd94e3fde92b9d4335c0565
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 10:36:55 2013 +0100
Added security warnings for the most sensitive settings.
commit 718d84bd8ac4a42fb4b28ec93965de32680f091e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:24:06 2013 +0100
Used an absolute path for the SQLite database.
This ensures the settings file works regardless of which directory
django-admin.py / manage.py is invoked from.
BASE_DIR got a +1 from a BDFL and another core dev. It doesn't involve
the concept of a "Django project"; it's just a convenient way to express
relative paths within the source code repository for non-Python files.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 1b559b4bcda622e10909b68fe5cab90db6727dd9
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:22:40 2013 +0100
Removed STATIC_ROOT from the default settings template.
It isn't necessary in development, and it confuses beginners to no end.
Thanks Carl Meyer for the suggestion.
commit a55f141a500bb7c9a1bc259bbe1954c13b199671
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:21:43 2013 +0100
Removed MEDIA_ROOT/URL from default settings template.
Many sites will never deal with user-uploaded files, and MEDIA_ROOT is
complicated to explain.
Thanks Carl Meyer for the suggestion.
commit 44bf2f2441420fd9429ee9fe1f7207f92dd87e70
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:22:09 2013 +0100
Removed logging config.
This configuration is applied regardless of the value of LOGGING;
duplicating it in LOGGING is confusing.
commit eac747e848eaed65fd5f6f254f0a7559d856f88f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:05:31 2013 +0100
Enabled the locale middleware by default.
USE_I18N is True by default, and doesn't work well without
LocaleMiddleware.
commit d806c62b2d00826dc2688c84b092627b8d571cab
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:03:16 2013 +0100
Enabled clickjacking protection by default.
commit 99152c30e6a15003f0b6737dc78e87adf462aacb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:01:48 2013 +0100
Reorganized settings in logical sections, and trimmed comments.
commit d37ffdfcb24b7e0ec7cc113d07190f65fb12fb8a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:54:11 2013 +0100
Avoided misleading TEMPLATE_DEBUG = DEBUG.
According to the docs TEMPLATE_DEBUG works only when DEBUG = True.
commit 15d9478d3a9850e85841e7cf09cf83050371c6bf
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:46:25 2013 +0100
Removed STATICFILES_FINDERS/TEMPLATE_LOADERS from default settings file.
Only developers with special needs ever need to change these settings.
commit 574da0eb5bfb4570883756914b4dbd7e20e1f61e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:45:01 2013 +0100
Removed STATICFILES/TEMPLATES_DIRS from default settings file.
The current best practice is to put static files and templates in
applications, for easier testing and deployment.
commit 8cb18dbe56629aa1be74718a07e7cc66b4f9c9f0
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:24:16 2013 +0100
Removed settings related to email reporting from default settings file.
While handy for small scale projects, it isn't exactly a best practice.
commit 8ecbfcb3638058f0c49922540f874a7d802d864f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 18:54:43 2013 +0100
Documented how to enable the sites framework.
commit 23fc91a6fa67d91ddd9d71b1c3e0dc26bdad9841
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:28:59 2013 +0100
Disabled the sites framework by default.
RequestSite does the job for single-domain websites.
commit c4d82eb8afc0eb8568bf9c4d12644272415e3960
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 00:08:33 2013 +0100
Added a default admin.py to the application template.
Thanks Ryan D Hiebert for the suggestion.
commit 4071dc771e5c44b1c5ebb9beecefb164ae465e22
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:59:49 2013 +0100
Enabled the admin by default.
Everyone uses the admin.
commit c807a31f8d89e7e7fd97380e3023f7983a8b6fcb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:57:05 2013 +0100
Removed admindocs from default project template.
commit 09e4ce0e652a97da1a9e285046a91c8ad7a9189c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:32:52 2013 +0100
Added links to the settings documentation.
commit 5b8f5eaef364eb790fcde6f9e86f7d266074cca8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 11:06:54 2013 +0100
Used a significant example for URLconf includes.
commit 908e91d6fcee2a3cb51ca26ecdf12a6a24e69ef8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:22:31 2013 +0100
Moved code comments about WSGI to docs, and rewrote said docs.
commit 50417e51996146f891d08ca8b74dcc736a581932
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 15:51:50 2013 +0100
Normalized the default application template.
Removed the default test that 1 + 1 = 2, because it's been committed
way too many times, in too many projects.
Added an import of `render` for views, because the first view will
often be:
def home(request):
return render(request, "mysite/home.html")
2013-01-28 14:51:50 +00:00
|
|
|
|
.. _custom-app-and-project-templates:
|
|
|
|
|
|
2011-12-22 22:38:02 +00:00
|
|
|
|
.. django-admin-option:: --template
|
|
|
|
|
|
2011-12-30 18:14:31 +00:00
|
|
|
|
With the ``--template`` option, you can use a custom app template by providing
|
|
|
|
|
either the path to a directory with the app template file, or a path to a
|
2011-12-22 22:38:02 +00:00
|
|
|
|
compressed file (``.tar.gz``, ``.tar.bz2``, ``.tgz``, ``.tbz``, ``.zip``)
|
|
|
|
|
containing the app template files.
|
|
|
|
|
|
2012-11-16 05:17:58 +00:00
|
|
|
|
For example, this would look for an app template in the given directory when
|
|
|
|
|
creating the ``myapp`` app::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
|
2012-11-16 05:17:58 +00:00
|
|
|
|
|
2011-12-30 18:14:31 +00:00
|
|
|
|
Django will also accept URLs (``http``, ``https``, ``ftp``) to compressed
|
|
|
|
|
archives with the app template files, downloading and extracting them on the
|
|
|
|
|
fly.
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2012-11-16 05:17:58 +00:00
|
|
|
|
For example, taking advantage of Github's feature to expose repositories as
|
|
|
|
|
zip files, you can use a URL like::
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2012-02-17 20:04:11 +00:00
|
|
|
|
When Django copies the app template files, it also renders certain files
|
|
|
|
|
through the template engine: the files whose extensions match the
|
|
|
|
|
``--extension`` option (``py`` by default) and the files whose names are passed
|
|
|
|
|
with the ``--name`` option. The :class:`template context
|
2011-12-22 22:38:02 +00:00
|
|
|
|
<django.template.Context>` used is:
|
|
|
|
|
|
2014-03-11 12:09:44 +00:00
|
|
|
|
- Any option passed to the ``startapp`` command (among the command's supported
|
2012-07-07 21:08:43 +00:00
|
|
|
|
options)
|
2011-12-30 18:14:31 +00:00
|
|
|
|
- ``app_name`` -- the app name as passed to the command
|
2011-12-22 22:38:02 +00:00
|
|
|
|
- ``app_directory`` -- the full path of the newly created app
|
2015-06-13 13:41:56 +00:00
|
|
|
|
- ``camel_case_app_name`` -- the app name in camel case format
|
Simplified default project template.
Squashed commit of:
commit 508ec9144b35c50794708225b496bde1eb5e60aa
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 22:50:55 2013 +0100
Tweaked default settings file.
* Explained why BASE_DIR exists.
* Added a link to the database configuration options, and put it in its
own section.
* Moved sensitive settings that must be changed for production at the
top.
commit 6515fd2f1aa73a86dc8dbd2ccf512ddb6b140d57
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 14:35:21 2013 +0100
Documented the simplified app & project templates in the changelog.
commit 2c5b576c2ea91d84273a019b3d0b3b8b4da72f23
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:59:27 2013 +0100
Minor fixes in tutorials 5 and 6.
commit 55a51531be8104f21b3cca3f6bf70b0a7139a041
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:51:11 2013 +0100
Updated tutorial 2 for the new project template.
commit 29ddae87bdaecff12dd31b16b000c01efbde9e20
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:58:54 2013 +0100
Updated tutorial 1 for the new project template.
commit 0ecb9f6e2514cfd26a678a280d471433375101a3
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:29:13 2013 +0100
Adjusted the default URLconf detection to account for the admin.
It's now enabled by default.
commit 5fb4da0d3d09dac28dd94e3fde92b9d4335c0565
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 10:36:55 2013 +0100
Added security warnings for the most sensitive settings.
commit 718d84bd8ac4a42fb4b28ec93965de32680f091e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:24:06 2013 +0100
Used an absolute path for the SQLite database.
This ensures the settings file works regardless of which directory
django-admin.py / manage.py is invoked from.
BASE_DIR got a +1 from a BDFL and another core dev. It doesn't involve
the concept of a "Django project"; it's just a convenient way to express
relative paths within the source code repository for non-Python files.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 1b559b4bcda622e10909b68fe5cab90db6727dd9
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:22:40 2013 +0100
Removed STATIC_ROOT from the default settings template.
It isn't necessary in development, and it confuses beginners to no end.
Thanks Carl Meyer for the suggestion.
commit a55f141a500bb7c9a1bc259bbe1954c13b199671
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:21:43 2013 +0100
Removed MEDIA_ROOT/URL from default settings template.
Many sites will never deal with user-uploaded files, and MEDIA_ROOT is
complicated to explain.
Thanks Carl Meyer for the suggestion.
commit 44bf2f2441420fd9429ee9fe1f7207f92dd87e70
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:22:09 2013 +0100
Removed logging config.
This configuration is applied regardless of the value of LOGGING;
duplicating it in LOGGING is confusing.
commit eac747e848eaed65fd5f6f254f0a7559d856f88f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:05:31 2013 +0100
Enabled the locale middleware by default.
USE_I18N is True by default, and doesn't work well without
LocaleMiddleware.
commit d806c62b2d00826dc2688c84b092627b8d571cab
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:03:16 2013 +0100
Enabled clickjacking protection by default.
commit 99152c30e6a15003f0b6737dc78e87adf462aacb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:01:48 2013 +0100
Reorganized settings in logical sections, and trimmed comments.
commit d37ffdfcb24b7e0ec7cc113d07190f65fb12fb8a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:54:11 2013 +0100
Avoided misleading TEMPLATE_DEBUG = DEBUG.
According to the docs TEMPLATE_DEBUG works only when DEBUG = True.
commit 15d9478d3a9850e85841e7cf09cf83050371c6bf
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:46:25 2013 +0100
Removed STATICFILES_FINDERS/TEMPLATE_LOADERS from default settings file.
Only developers with special needs ever need to change these settings.
commit 574da0eb5bfb4570883756914b4dbd7e20e1f61e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:45:01 2013 +0100
Removed STATICFILES/TEMPLATES_DIRS from default settings file.
The current best practice is to put static files and templates in
applications, for easier testing and deployment.
commit 8cb18dbe56629aa1be74718a07e7cc66b4f9c9f0
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:24:16 2013 +0100
Removed settings related to email reporting from default settings file.
While handy for small scale projects, it isn't exactly a best practice.
commit 8ecbfcb3638058f0c49922540f874a7d802d864f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 18:54:43 2013 +0100
Documented how to enable the sites framework.
commit 23fc91a6fa67d91ddd9d71b1c3e0dc26bdad9841
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:28:59 2013 +0100
Disabled the sites framework by default.
RequestSite does the job for single-domain websites.
commit c4d82eb8afc0eb8568bf9c4d12644272415e3960
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 00:08:33 2013 +0100
Added a default admin.py to the application template.
Thanks Ryan D Hiebert for the suggestion.
commit 4071dc771e5c44b1c5ebb9beecefb164ae465e22
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:59:49 2013 +0100
Enabled the admin by default.
Everyone uses the admin.
commit c807a31f8d89e7e7fd97380e3023f7983a8b6fcb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:57:05 2013 +0100
Removed admindocs from default project template.
commit 09e4ce0e652a97da1a9e285046a91c8ad7a9189c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:32:52 2013 +0100
Added links to the settings documentation.
commit 5b8f5eaef364eb790fcde6f9e86f7d266074cca8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 11:06:54 2013 +0100
Used a significant example for URLconf includes.
commit 908e91d6fcee2a3cb51ca26ecdf12a6a24e69ef8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:22:31 2013 +0100
Moved code comments about WSGI to docs, and rewrote said docs.
commit 50417e51996146f891d08ca8b74dcc736a581932
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 15:51:50 2013 +0100
Normalized the default application template.
Removed the default test that 1 + 1 = 2, because it's been committed
way too many times, in too many projects.
Added an import of `render` for views, because the first view will
often be:
def home(request):
return render(request, "mysite/home.html")
2013-01-28 14:51:50 +00:00
|
|
|
|
- ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'``
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2015-06-13 13:41:56 +00:00
|
|
|
|
.. versionadded:: 1.9
|
|
|
|
|
|
|
|
|
|
``camel_case_app_name`` was added.
|
|
|
|
|
|
2011-12-22 22:38:02 +00:00
|
|
|
|
.. _render_warning:
|
|
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
When the app template files are rendered with the Django template
|
2011-12-30 18:14:31 +00:00
|
|
|
|
engine (by default all ``*.py`` files), Django will also replace all
|
|
|
|
|
stray template variables contained. For example, if one of the Python files
|
|
|
|
|
contains a docstring explaining a particular feature related
|
2011-12-22 22:38:02 +00:00
|
|
|
|
to template rendering, it might result in an incorrect example.
|
|
|
|
|
|
2011-12-30 18:14:31 +00:00
|
|
|
|
To work around this problem, you can use the :ttag:`templatetag`
|
2011-12-22 22:38:02 +00:00
|
|
|
|
templatetag to "escape" the various parts of the template syntax.
|
|
|
|
|
|
2012-05-03 15:42:56 +00:00
|
|
|
|
.. _source: https://github.com/django/django/tree/master/django/conf/app_template/
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
|
|
|
|
startproject <projectname> [destination]
|
|
|
|
|
----------------------------------------
|
2005-08-10 20:24:51 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: startproject
|
|
|
|
|
|
2011-12-22 22:38:02 +00:00
|
|
|
|
Creates a Django project directory structure for the given project name in
|
|
|
|
|
the current directory or the given destination.
|
|
|
|
|
|
2011-12-30 18:14:31 +00:00
|
|
|
|
By default, the new directory contains ``manage.py`` and a project package
|
2012-02-03 17:52:39 +00:00
|
|
|
|
(containing a ``settings.py`` and other files). See the `template source`_ for
|
2012-01-04 23:55:34 +00:00
|
|
|
|
details.
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
|
|
|
|
If only the project name is given, both the project directory and project
|
|
|
|
|
package will be named ``<projectname>`` and the project directory
|
|
|
|
|
will be created in the current working directory.
|
|
|
|
|
|
2012-01-04 23:55:34 +00:00
|
|
|
|
If the optional destination is provided, Django will use that existing
|
|
|
|
|
directory as the project directory, and create ``manage.py`` and the project
|
2012-02-03 17:52:39 +00:00
|
|
|
|
package within it. Use '.' to denote the current working directory.
|
2011-12-30 18:14:31 +00:00
|
|
|
|
|
|
|
|
|
For example::
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2011-12-30 18:14:31 +00:00
|
|
|
|
As with the :djadmin:`startapp` command, the ``--template`` option lets you
|
2012-02-03 20:45:45 +00:00
|
|
|
|
specify a directory, file path or URL of a custom project template. See the
|
2011-12-30 18:14:31 +00:00
|
|
|
|
:djadmin:`startapp` documentation for details of supported project template
|
|
|
|
|
formats.
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
|
|
|
|
For example, this would look for a project template in the given directory
|
|
|
|
|
when creating the ``myproject`` project::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin startproject --template=/Users/jezdez/Code/my_project_template myproject
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2012-11-16 05:17:58 +00:00
|
|
|
|
Django will also accept URLs (``http``, ``https``, ``ftp``) to compressed
|
|
|
|
|
archives with the project template files, downloading and extracting them on the
|
|
|
|
|
fly.
|
|
|
|
|
|
|
|
|
|
For example, taking advantage of Github's feature to expose repositories as
|
|
|
|
|
zip files, you can use a URL like::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin startproject --template=https://github.com/githubuser/django-project-template/archive/master.zip myproject
|
2012-11-16 05:17:58 +00:00
|
|
|
|
|
2012-02-17 20:04:11 +00:00
|
|
|
|
When Django copies the project template files, it also renders certain files
|
|
|
|
|
through the template engine: the files whose extensions match the
|
|
|
|
|
``--extension`` option (``py`` by default) and the files whose names are passed
|
|
|
|
|
with the ``--name`` option. The :class:`template context
|
2011-12-22 22:38:02 +00:00
|
|
|
|
<django.template.Context>` used is:
|
|
|
|
|
|
2014-03-11 12:09:44 +00:00
|
|
|
|
- Any option passed to the ``startproject`` command (among the command's
|
|
|
|
|
supported options)
|
2011-12-22 22:38:02 +00:00
|
|
|
|
- ``project_name`` -- the project name as passed to the command
|
|
|
|
|
- ``project_directory`` -- the full path of the newly created project
|
|
|
|
|
- ``secret_key`` -- a random key for the :setting:`SECRET_KEY` setting
|
Simplified default project template.
Squashed commit of:
commit 508ec9144b35c50794708225b496bde1eb5e60aa
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 22:50:55 2013 +0100
Tweaked default settings file.
* Explained why BASE_DIR exists.
* Added a link to the database configuration options, and put it in its
own section.
* Moved sensitive settings that must be changed for production at the
top.
commit 6515fd2f1aa73a86dc8dbd2ccf512ddb6b140d57
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 14:35:21 2013 +0100
Documented the simplified app & project templates in the changelog.
commit 2c5b576c2ea91d84273a019b3d0b3b8b4da72f23
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:59:27 2013 +0100
Minor fixes in tutorials 5 and 6.
commit 55a51531be8104f21b3cca3f6bf70b0a7139a041
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:51:11 2013 +0100
Updated tutorial 2 for the new project template.
commit 29ddae87bdaecff12dd31b16b000c01efbde9e20
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:58:54 2013 +0100
Updated tutorial 1 for the new project template.
commit 0ecb9f6e2514cfd26a678a280d471433375101a3
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:29:13 2013 +0100
Adjusted the default URLconf detection to account for the admin.
It's now enabled by default.
commit 5fb4da0d3d09dac28dd94e3fde92b9d4335c0565
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 10:36:55 2013 +0100
Added security warnings for the most sensitive settings.
commit 718d84bd8ac4a42fb4b28ec93965de32680f091e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:24:06 2013 +0100
Used an absolute path for the SQLite database.
This ensures the settings file works regardless of which directory
django-admin.py / manage.py is invoked from.
BASE_DIR got a +1 from a BDFL and another core dev. It doesn't involve
the concept of a "Django project"; it's just a convenient way to express
relative paths within the source code repository for non-Python files.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 1b559b4bcda622e10909b68fe5cab90db6727dd9
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:22:40 2013 +0100
Removed STATIC_ROOT from the default settings template.
It isn't necessary in development, and it confuses beginners to no end.
Thanks Carl Meyer for the suggestion.
commit a55f141a500bb7c9a1bc259bbe1954c13b199671
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:21:43 2013 +0100
Removed MEDIA_ROOT/URL from default settings template.
Many sites will never deal with user-uploaded files, and MEDIA_ROOT is
complicated to explain.
Thanks Carl Meyer for the suggestion.
commit 44bf2f2441420fd9429ee9fe1f7207f92dd87e70
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:22:09 2013 +0100
Removed logging config.
This configuration is applied regardless of the value of LOGGING;
duplicating it in LOGGING is confusing.
commit eac747e848eaed65fd5f6f254f0a7559d856f88f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:05:31 2013 +0100
Enabled the locale middleware by default.
USE_I18N is True by default, and doesn't work well without
LocaleMiddleware.
commit d806c62b2d00826dc2688c84b092627b8d571cab
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:03:16 2013 +0100
Enabled clickjacking protection by default.
commit 99152c30e6a15003f0b6737dc78e87adf462aacb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:01:48 2013 +0100
Reorganized settings in logical sections, and trimmed comments.
commit d37ffdfcb24b7e0ec7cc113d07190f65fb12fb8a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:54:11 2013 +0100
Avoided misleading TEMPLATE_DEBUG = DEBUG.
According to the docs TEMPLATE_DEBUG works only when DEBUG = True.
commit 15d9478d3a9850e85841e7cf09cf83050371c6bf
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:46:25 2013 +0100
Removed STATICFILES_FINDERS/TEMPLATE_LOADERS from default settings file.
Only developers with special needs ever need to change these settings.
commit 574da0eb5bfb4570883756914b4dbd7e20e1f61e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:45:01 2013 +0100
Removed STATICFILES/TEMPLATES_DIRS from default settings file.
The current best practice is to put static files and templates in
applications, for easier testing and deployment.
commit 8cb18dbe56629aa1be74718a07e7cc66b4f9c9f0
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:24:16 2013 +0100
Removed settings related to email reporting from default settings file.
While handy for small scale projects, it isn't exactly a best practice.
commit 8ecbfcb3638058f0c49922540f874a7d802d864f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 18:54:43 2013 +0100
Documented how to enable the sites framework.
commit 23fc91a6fa67d91ddd9d71b1c3e0dc26bdad9841
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:28:59 2013 +0100
Disabled the sites framework by default.
RequestSite does the job for single-domain websites.
commit c4d82eb8afc0eb8568bf9c4d12644272415e3960
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 00:08:33 2013 +0100
Added a default admin.py to the application template.
Thanks Ryan D Hiebert for the suggestion.
commit 4071dc771e5c44b1c5ebb9beecefb164ae465e22
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:59:49 2013 +0100
Enabled the admin by default.
Everyone uses the admin.
commit c807a31f8d89e7e7fd97380e3023f7983a8b6fcb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:57:05 2013 +0100
Removed admindocs from default project template.
commit 09e4ce0e652a97da1a9e285046a91c8ad7a9189c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:32:52 2013 +0100
Added links to the settings documentation.
commit 5b8f5eaef364eb790fcde6f9e86f7d266074cca8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 11:06:54 2013 +0100
Used a significant example for URLconf includes.
commit 908e91d6fcee2a3cb51ca26ecdf12a6a24e69ef8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:22:31 2013 +0100
Moved code comments about WSGI to docs, and rewrote said docs.
commit 50417e51996146f891d08ca8b74dcc736a581932
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 15:51:50 2013 +0100
Normalized the default application template.
Removed the default test that 1 + 1 = 2, because it's been committed
way too many times, in too many projects.
Added an import of `render` for views, because the first view will
often be:
def home(request):
return render(request, "mysite/home.html")
2013-01-28 14:51:50 +00:00
|
|
|
|
- ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'``
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
|
|
|
|
Please also see the :ref:`rendering warning <render_warning>` as mentioned
|
|
|
|
|
for :djadmin:`startapp`.
|
|
|
|
|
|
2012-05-03 15:42:56 +00:00
|
|
|
|
.. _`template source`: https://github.com/django/django/tree/master/django/conf/project_template/
|
2011-12-22 22:38:02 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
test <app or test identifier>
|
|
|
|
|
-----------------------------
|
2007-09-09 21:57:59 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: test
|
2006-08-29 18:04:09 +00:00
|
|
|
|
|
2012-12-22 00:59:06 +00:00
|
|
|
|
Runs tests for all installed models. See :doc:`/topics/testing/index` for more
|
2008-08-23 22:25:40 +00:00
|
|
|
|
information.
|
2007-08-16 23:05:00 +00:00
|
|
|
|
|
2009-12-31 18:48:28 +00:00
|
|
|
|
.. django-admin-option:: --failfast
|
2009-12-13 16:24:36 +00:00
|
|
|
|
|
Fixed #2879 -- Added support for the integration with Selenium and other in-browser testing frameworks. Also added the first Selenium tests for `contrib.admin`. Many thanks to everyone for their contributions and feedback: Mikeal Rogers, Dirk Datzert, mir, Simon G., Almad, Russell Keith-Magee, Denis Golomazov, devin, robertrv, andrewbadr, Idan Gazit, voidspace, Tom Christie, hjwp2, Adam Nelson, Jannis Leidel, Anssi Kääriäinen, Preston Holmes, Bruno Renié and Jacob Kaplan-Moss.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17241 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2011-12-22 08:33:58 +00:00
|
|
|
|
The ``--failfast`` option can be used to stop running tests and report the
|
|
|
|
|
failure immediately after a test fails.
|
2009-12-13 16:24:36 +00:00
|
|
|
|
|
2011-06-10 08:26:05 +00:00
|
|
|
|
.. django-admin-option:: --testrunner
|
|
|
|
|
|
Fixed #2879 -- Added support for the integration with Selenium and other in-browser testing frameworks. Also added the first Selenium tests for `contrib.admin`. Many thanks to everyone for their contributions and feedback: Mikeal Rogers, Dirk Datzert, mir, Simon G., Almad, Russell Keith-Magee, Denis Golomazov, devin, robertrv, andrewbadr, Idan Gazit, voidspace, Tom Christie, hjwp2, Adam Nelson, Jannis Leidel, Anssi Kääriäinen, Preston Holmes, Bruno Renié and Jacob Kaplan-Moss.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17241 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2011-12-22 08:33:58 +00:00
|
|
|
|
The ``--testrunner`` option can be used to control the test runner class that
|
|
|
|
|
is used to execute tests. If this value is provided, it overrides the value
|
|
|
|
|
provided by the :setting:`TEST_RUNNER` setting.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --liveserver
|
|
|
|
|
|
|
|
|
|
The ``--liveserver`` option can be used to override the default address where
|
|
|
|
|
the live server (used with :class:`~django.test.LiveServerTestCase`) is
|
|
|
|
|
expected to run from. The default value is ``localhost:8081``.
|
2011-06-10 08:26:05 +00:00
|
|
|
|
|
2014-05-27 21:13:08 +00:00
|
|
|
|
.. django-admin-option:: --keepdb
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
The ``--keepdb`` option can be used to preserve the test database between test
|
|
|
|
|
runs. This has the advantage of skipping both the create and destroy actions
|
2015-05-07 23:41:42 +00:00
|
|
|
|
which can greatly decrease the time to run tests, especially those in a large
|
2014-05-27 21:13:08 +00:00
|
|
|
|
test suite. If the test database does not exist, it will be created on the first
|
|
|
|
|
run and then preserved for each subsequent run. Any unapplied migrations will also
|
|
|
|
|
be applied to the test database before running the test suite.
|
|
|
|
|
|
2014-11-22 16:59:05 +00:00
|
|
|
|
.. django-admin-option:: --reverse
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
The ``--reverse`` option can be used to sort test cases in the opposite order.
|
2015-05-07 23:41:42 +00:00
|
|
|
|
This may help in debugging the side effects of tests that aren't properly
|
|
|
|
|
isolated. :ref:`Grouping by test class <order-of-tests>` is preserved when using
|
2014-11-22 16:59:05 +00:00
|
|
|
|
this option.
|
|
|
|
|
|
2015-01-10 22:52:59 +00:00
|
|
|
|
.. django-admin-option:: --debug-sql
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
The ``--debug-sql`` option can be used to enable :ref:`SQL logging
|
|
|
|
|
<django-db-logger>` for failing tests. If :djadminopt:`--verbosity` is ``2``,
|
|
|
|
|
then queries in passing tests are also output.
|
|
|
|
|
|
2007-09-09 21:57:59 +00:00
|
|
|
|
testserver <fixture fixture ...>
|
2007-08-16 23:05:00 +00:00
|
|
|
|
--------------------------------
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin:: testserver
|
|
|
|
|
|
2013-11-18 18:25:28 +00:00
|
|
|
|
Runs a Django development server (as in :djadmin:`runserver`) using data from
|
|
|
|
|
the given fixture(s).
|
2007-08-16 23:05:00 +00:00
|
|
|
|
|
|
|
|
|
For example, this command::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin testserver mydata.json
|
2007-08-16 23:05:00 +00:00
|
|
|
|
|
|
|
|
|
...would perform the following steps:
|
|
|
|
|
|
2012-12-22 00:59:06 +00:00
|
|
|
|
1. Create a test database, as described in :ref:`the-test-database`.
|
2011-10-14 00:12:01 +00:00
|
|
|
|
2. Populate the test database with fixture data from the given fixtures.
|
2013-11-18 18:25:28 +00:00
|
|
|
|
(For more on fixtures, see the documentation for :djadmin:`loaddata` above.)
|
|
|
|
|
3. Runs the Django development server (as in :djadmin:`runserver`), pointed at
|
2011-10-14 00:12:01 +00:00
|
|
|
|
this newly created test database instead of your production database.
|
2007-08-16 23:05:00 +00:00
|
|
|
|
|
|
|
|
|
This is useful in a number of ways:
|
|
|
|
|
|
2012-12-22 00:59:06 +00:00
|
|
|
|
* When you're writing :doc:`unit tests </topics/testing/overview>` of how your views
|
2011-10-14 00:12:01 +00:00
|
|
|
|
act with certain fixture data, you can use ``testserver`` to interact with
|
|
|
|
|
the views in a Web browser, manually.
|
2007-08-16 23:05:00 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* Let's say you're developing your Django application and have a "pristine"
|
|
|
|
|
copy of a database that you'd like to interact with. You can dump your
|
2013-11-18 18:25:28 +00:00
|
|
|
|
database to a fixture (using the :djadmin:`dumpdata` command, explained
|
|
|
|
|
above), then use ``testserver`` to run your Web application with that data.
|
|
|
|
|
With this arrangement, you have the flexibility of messing up your data
|
2011-10-14 00:12:01 +00:00
|
|
|
|
in any way, knowing that whatever data changes you're making are only
|
|
|
|
|
being made to a test database.
|
2007-08-16 23:05:00 +00:00
|
|
|
|
|
2007-09-14 19:17:15 +00:00
|
|
|
|
Note that this server does *not* automatically detect changes to your Python
|
2013-11-18 18:25:28 +00:00
|
|
|
|
source code (as :djadmin:`runserver` does). It does, however, detect changes to
|
2007-09-14 19:17:15 +00:00
|
|
|
|
templates.
|
2007-08-25 23:56:33 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --addrport [port number or ipaddr:port]
|
2007-09-14 19:17:15 +00:00
|
|
|
|
|
|
|
|
|
Use ``--addrport`` to specify a different port, or IP address and port, from
|
2010-11-26 13:33:53 +00:00
|
|
|
|
the default of ``127.0.0.1:8000``. This value follows exactly the same format and
|
2013-11-18 18:25:28 +00:00
|
|
|
|
serves exactly the same function as the argument to the :djadmin:`runserver`
|
|
|
|
|
command.
|
2007-09-14 19:17:15 +00:00
|
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
|
|
To run the test server on port 7000 with ``fixture1`` and ``fixture2``::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin testserver --addrport 7000 fixture1 fixture2
|
|
|
|
|
django-admin testserver fixture1 fixture2 --addrport 7000
|
2007-09-14 19:17:15 +00:00
|
|
|
|
|
|
|
|
|
(The above statements are equivalent. We include both of them to demonstrate
|
2007-09-16 16:01:25 +00:00
|
|
|
|
that it doesn't matter whether the options come before or after the fixture
|
|
|
|
|
arguments.)
|
2007-09-14 19:17:15 +00:00
|
|
|
|
|
2007-11-29 18:15:38 +00:00
|
|
|
|
To run on 1.2.3.4:7000 with a ``test`` fixture::
|
2007-09-14 19:17:15 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin testserver --addrport 1.2.3.4:7000 test
|
2007-09-14 19:17:15 +00:00
|
|
|
|
|
2010-06-21 12:09:25 +00:00
|
|
|
|
The :djadminopt:`--noinput` option may be provided to suppress all user
|
|
|
|
|
prompts.
|
|
|
|
|
|
2010-10-23 16:37:51 +00:00
|
|
|
|
Commands provided by applications
|
|
|
|
|
=================================
|
|
|
|
|
|
|
|
|
|
Some commands are only available when the ``django.contrib`` application that
|
|
|
|
|
:doc:`implements </howto/custom-management-commands>` them has been
|
|
|
|
|
:setting:`enabled <INSTALLED_APPS>`. This section describes them grouped by
|
|
|
|
|
their application.
|
|
|
|
|
|
|
|
|
|
``django.contrib.auth``
|
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
|
|
changepassword
|
|
|
|
|
~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
.. django-admin:: changepassword
|
|
|
|
|
|
|
|
|
|
This command is only available if Django's :doc:`authentication system
|
2012-12-28 19:00:11 +00:00
|
|
|
|
</topics/auth/index>` (``django.contrib.auth``) is installed.
|
2010-10-23 16:37:51 +00:00
|
|
|
|
|
2015-05-07 23:41:42 +00:00
|
|
|
|
Allows changing a user's password. It prompts you to enter a new password twice
|
|
|
|
|
for the given user. If the entries are identical, this immediately becomes the
|
|
|
|
|
new password. If you do not supply a user, the command will attempt to change
|
|
|
|
|
the password whose username matches the current user.
|
2010-10-23 16:37:51 +00:00
|
|
|
|
|
2012-03-12 20:05:48 +00:00
|
|
|
|
Use the ``--database`` option to specify the database to query for the user. If
|
|
|
|
|
it's not supplied, Django will use the ``default`` database.
|
2012-03-05 04:17:55 +00:00
|
|
|
|
|
2010-10-23 16:37:51 +00:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin changepassword ringo
|
2010-10-23 16:37:51 +00:00
|
|
|
|
|
|
|
|
|
createsuperuser
|
|
|
|
|
~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
.. django-admin:: createsuperuser
|
|
|
|
|
|
|
|
|
|
This command is only available if Django's :doc:`authentication system
|
2012-12-28 19:00:11 +00:00
|
|
|
|
</topics/auth/index>` (``django.contrib.auth``) is installed.
|
2010-10-23 16:37:51 +00:00
|
|
|
|
|
|
|
|
|
Creates a superuser account (a user who has all permissions). This is
|
2014-06-10 16:22:07 +00:00
|
|
|
|
useful if you need to create an initial superuser account or if you need to
|
|
|
|
|
programmatically generate superuser accounts for your site(s).
|
2010-10-23 16:37:51 +00:00
|
|
|
|
|
|
|
|
|
When run interactively, this command will prompt for a password for
|
|
|
|
|
the new superuser account. When run non-interactively, no password
|
|
|
|
|
will be set, and the superuser account will not be able to log in until
|
|
|
|
|
a password has been manually set for it.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --username
|
|
|
|
|
.. django-admin-option:: --email
|
|
|
|
|
|
2011-04-01 16:10:22 +00:00
|
|
|
|
The username and email address for the new account can be supplied by
|
2010-10-23 16:37:51 +00:00
|
|
|
|
using the ``--username`` and ``--email`` arguments on the command
|
|
|
|
|
line. If either of those is not supplied, ``createsuperuser`` will prompt for
|
|
|
|
|
it when running interactively.
|
|
|
|
|
|
2012-03-12 20:05:48 +00:00
|
|
|
|
Use the ``--database`` option to specify the database into which the superuser
|
|
|
|
|
object will be saved.
|
2012-03-05 04:17:55 +00:00
|
|
|
|
|
2014-07-03 18:30:17 +00:00
|
|
|
|
.. versionadded:: 1.8
|
|
|
|
|
|
|
|
|
|
You can subclass the management command and override ``get_input_data()`` if you
|
|
|
|
|
want to customize data input and validation. Consult the source code for
|
|
|
|
|
details on the existing implementation and the method's parameters. For example,
|
|
|
|
|
it could be useful if you have a ``ForeignKey`` in
|
|
|
|
|
:attr:`~django.contrib.auth.models.CustomUser.REQUIRED_FIELDS` and want to
|
|
|
|
|
allow creating an instance instead of entering the primary key of an existing
|
|
|
|
|
instance.
|
|
|
|
|
|
2010-10-23 16:37:51 +00:00
|
|
|
|
``django.contrib.gis``
|
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
|
|
ogrinspect
|
|
|
|
|
~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
This command is only available if :doc:`GeoDjango </ref/contrib/gis/index>`
|
|
|
|
|
(``django.contrib.gis``) is installed.
|
|
|
|
|
|
|
|
|
|
Please refer to its :djadmin:`description <ogrinspect>` in the GeoDjango
|
|
|
|
|
documentation.
|
|
|
|
|
|
2012-10-27 09:49:46 +00:00
|
|
|
|
``django.contrib.sessions``
|
|
|
|
|
---------------------------
|
|
|
|
|
|
|
|
|
|
clearsessions
|
|
|
|
|
~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
.. django-admin:: clearsessions
|
|
|
|
|
|
|
|
|
|
Can be run as a cron job or directly to clean out expired sessions.
|
|
|
|
|
|
2010-10-23 16:37:51 +00:00
|
|
|
|
``django.contrib.sitemaps``
|
|
|
|
|
---------------------------
|
|
|
|
|
|
|
|
|
|
ping_google
|
|
|
|
|
~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
This command is only available if the :doc:`Sitemaps framework
|
|
|
|
|
</ref/contrib/sitemaps>` (``django.contrib.sitemaps``) is installed.
|
|
|
|
|
|
|
|
|
|
Please refer to its :djadmin:`description <ping_google>` in the Sitemaps
|
|
|
|
|
documentation.
|
|
|
|
|
|
|
|
|
|
``django.contrib.staticfiles``
|
|
|
|
|
------------------------------
|
|
|
|
|
|
|
|
|
|
collectstatic
|
|
|
|
|
~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
This command is only available if the :doc:`static files application
|
2013-03-07 19:15:39 +00:00
|
|
|
|
</howto/static-files/index>` (``django.contrib.staticfiles``) is installed.
|
2010-10-23 16:37:51 +00:00
|
|
|
|
|
|
|
|
|
Please refer to its :djadmin:`description <collectstatic>` in the
|
|
|
|
|
:doc:`staticfiles </ref/contrib/staticfiles>` documentation.
|
|
|
|
|
|
|
|
|
|
findstatic
|
|
|
|
|
~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
This command is only available if the :doc:`static files application
|
2013-03-07 19:15:39 +00:00
|
|
|
|
</howto/static-files/index>` (``django.contrib.staticfiles``) is installed.
|
2010-10-23 16:37:51 +00:00
|
|
|
|
|
|
|
|
|
Please refer to its :djadmin:`description <findstatic>` in the :doc:`staticfiles
|
|
|
|
|
</ref/contrib/staticfiles>` documentation.
|
|
|
|
|
|
2007-09-09 21:57:59 +00:00
|
|
|
|
Default options
|
|
|
|
|
===============
|
|
|
|
|
|
2010-10-23 16:37:51 +00:00
|
|
|
|
Although some commands may allow their own custom options, every command
|
2007-09-09 21:57:59 +00:00
|
|
|
|
allows for the following options:
|
2006-01-11 02:06:27 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --pythonpath
|
2005-10-06 17:22:23 +00:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
|
2005-10-06 17:22:23 +00:00
|
|
|
|
|
2005-10-06 17:27:13 +00:00
|
|
|
|
Adds the given filesystem path to the Python `import search path`_. If this
|
2014-07-26 11:21:52 +00:00
|
|
|
|
isn't provided, ``django-admin`` will use the ``PYTHONPATH`` environment
|
2005-10-06 17:27:13 +00:00
|
|
|
|
variable.
|
|
|
|
|
|
2006-01-11 02:06:27 +00:00
|
|
|
|
Note that this option is unnecessary in ``manage.py``, because it takes care of
|
|
|
|
|
setting the Python path for you.
|
|
|
|
|
|
2014-06-10 19:16:31 +00:00
|
|
|
|
.. _import search path: http://www.diveintopython.net/getting_to_know_python/everything_is_an_object.html
|
2005-10-06 17:22:23 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --settings
|
2006-08-31 14:29:47 +00:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin migrate --settings=mysite.settings
|
2007-04-09 01:44:26 +00:00
|
|
|
|
|
2007-09-09 21:57:59 +00:00
|
|
|
|
Explicitly specifies the settings module to use. The settings module should be
|
|
|
|
|
in Python package syntax, e.g. ``mysite.settings``. If this isn't provided,
|
2014-07-26 11:21:52 +00:00
|
|
|
|
``django-admin`` will use the ``DJANGO_SETTINGS_MODULE`` environment
|
2007-09-09 21:57:59 +00:00
|
|
|
|
variable.
|
2006-09-24 08:22:52 +00:00
|
|
|
|
|
2008-01-02 05:08:25 +00:00
|
|
|
|
Note that this option is unnecessary in ``manage.py``, because it uses
|
2008-02-15 11:38:53 +00:00
|
|
|
|
``settings.py`` from the current project by default.
|
2006-09-24 08:22:52 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --traceback
|
2008-06-19 13:24:39 +00:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin migrate --traceback
|
2008-06-19 13:24:39 +00:00
|
|
|
|
|
2015-05-07 23:41:42 +00:00
|
|
|
|
By default, ``django-admin`` will show a simple error message whenever a
|
2013-03-09 11:38:45 +00:00
|
|
|
|
:class:`~django.core.management.CommandError` occurs, but a full stack trace
|
2014-07-26 11:21:52 +00:00
|
|
|
|
for any other exception. If you specify ``--traceback``, ``django-admin``
|
2013-03-09 11:38:45 +00:00
|
|
|
|
will also output a full stack trace when a ``CommandError`` is raised.
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --verbosity
|
2008-10-02 12:57:13 +00:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin migrate --verbosity 2
|
2008-10-02 12:57:13 +00:00
|
|
|
|
|
|
|
|
|
Use ``--verbosity`` to specify the amount of notification and debug information
|
2014-07-26 11:21:52 +00:00
|
|
|
|
that ``django-admin`` should print to the console.
|
2008-10-02 12:57:13 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``0`` means no output.
|
|
|
|
|
* ``1`` means normal output (default).
|
|
|
|
|
* ``2`` means verbose output.
|
|
|
|
|
* ``3`` means *very* verbose output.
|
2008-10-02 12:57:13 +00:00
|
|
|
|
|
2013-02-23 15:28:45 +00:00
|
|
|
|
.. django-admin-option:: --no-color
|
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin sqlall --no-color
|
2013-02-23 15:28:45 +00:00
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
By default, ``django-admin`` will format the output to be colorized. For
|
2013-02-23 15:28:45 +00:00
|
|
|
|
example, errors will be printed to the console in red and SQL statements will
|
|
|
|
|
be syntax highlighted. To prevent this and have a plain text output, pass the
|
|
|
|
|
``--no-color`` option when running your command.
|
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
Common options
|
|
|
|
|
==============
|
|
|
|
|
|
2011-08-22 06:30:42 +00:00
|
|
|
|
The following options are not available on every command, but they are common
|
|
|
|
|
to a number of commands.
|
2009-11-12 13:58:32 +00:00
|
|
|
|
|
2009-12-22 15:18:51 +00:00
|
|
|
|
.. django-admin-option:: --database
|
|
|
|
|
|
|
|
|
|
Used to specify the database on which a command will operate. If not
|
|
|
|
|
specified, this option will default to an alias of ``default``.
|
|
|
|
|
|
|
|
|
|
For example, to dump data from the database with the alias ``master``::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin dumpdata --database=master
|
2009-12-22 15:18:51 +00:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --exclude
|
|
|
|
|
|
|
|
|
|
Exclude a specific application from the applications whose contents is
|
2013-03-22 09:50:45 +00:00
|
|
|
|
output. For example, to specifically exclude the ``auth`` application from
|
2009-12-22 15:18:51 +00:00
|
|
|
|
the output of dumpdata, you would call::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin dumpdata --exclude=auth
|
2009-12-22 15:18:51 +00:00
|
|
|
|
|
|
|
|
|
If you want to exclude multiple applications, use multiple ``--exclude``
|
|
|
|
|
directives::
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
django-admin dumpdata --exclude=auth --exclude=contenttypes
|
2009-12-22 15:18:51 +00:00
|
|
|
|
|
2009-11-12 13:58:32 +00:00
|
|
|
|
.. django-admin-option:: --locale
|
|
|
|
|
|
|
|
|
|
Use the ``--locale`` or ``-l`` option to specify the locale to process.
|
|
|
|
|
If not provided all locales are processed.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --noinput
|
|
|
|
|
|
|
|
|
|
Use the ``--noinput`` option to suppress all user prompting, such as "Are
|
2014-07-26 11:21:52 +00:00
|
|
|
|
you sure?" confirmation messages. This is useful if ``django-admin`` is
|
2009-11-12 13:58:32 +00:00
|
|
|
|
being executed as an unattended, automated script.
|
|
|
|
|
|
2006-05-02 01:31:56 +00:00
|
|
|
|
Extra niceties
|
|
|
|
|
==============
|
|
|
|
|
|
2009-12-28 06:48:47 +00:00
|
|
|
|
.. _syntax-coloring:
|
|
|
|
|
|
2006-05-02 01:31:56 +00:00
|
|
|
|
Syntax coloring
|
|
|
|
|
---------------
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
The ``django-admin`` / ``manage.py`` commands will use pretty
|
2010-02-23 13:22:05 +00:00
|
|
|
|
color-coded output if your terminal supports ANSI-colored output. It
|
|
|
|
|
won't use the color codes if you're piping the command's output to
|
|
|
|
|
another program.
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
2013-12-03 02:11:59 +00:00
|
|
|
|
Under Windows, the native console doesn't support ANSI escape sequences so by
|
|
|
|
|
default there is no color output. But you can install the `ANSICON`_
|
|
|
|
|
third-party tool, the Django commands will detect its presence and will make
|
|
|
|
|
use of its services to color output just like on Unix-based platforms.
|
|
|
|
|
|
2009-12-28 06:48:47 +00:00
|
|
|
|
The colors used for syntax highlighting can be customized. Django
|
|
|
|
|
ships with three color palettes:
|
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``dark``, suited to terminals that show white text on a black
|
|
|
|
|
background. This is the default palette.
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``light``, suited to terminals that show black text on a white
|
|
|
|
|
background.
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``nocolor``, which disables syntax highlighting.
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
|
|
|
|
You select a palette by setting a ``DJANGO_COLORS`` environment
|
|
|
|
|
variable to specify the palette you want to use. For example, to
|
|
|
|
|
specify the ``light`` palette under a Unix or OS/X BASH shell, you
|
|
|
|
|
would run the following at a command prompt::
|
|
|
|
|
|
|
|
|
|
export DJANGO_COLORS="light"
|
|
|
|
|
|
|
|
|
|
You can also customize the colors that are used. Django specifies a
|
|
|
|
|
number of roles in which color is used:
|
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``error`` - A major error.
|
|
|
|
|
* ``notice`` - A minor error.
|
|
|
|
|
* ``sql_field`` - The name of a model field in SQL.
|
|
|
|
|
* ``sql_coltype`` - The type of a model field in SQL.
|
2013-09-05 22:23:48 +00:00
|
|
|
|
* ``sql_keyword`` - An SQL keyword.
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``sql_table`` - The name of a model in SQL.
|
|
|
|
|
* ``http_info`` - A 1XX HTTP Informational server response.
|
|
|
|
|
* ``http_success`` - A 2XX HTTP Success server response.
|
|
|
|
|
* ``http_not_modified`` - A 304 HTTP Not Modified server response.
|
|
|
|
|
* ``http_redirect`` - A 3XX HTTP Redirect server response other than 304.
|
|
|
|
|
* ``http_not_found`` - A 404 HTTP Not Found server response.
|
|
|
|
|
* ``http_bad_request`` - A 4XX HTTP Bad Request server response other than 404.
|
|
|
|
|
* ``http_server_error`` - A 5XX HTTP Server Error response.
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
|
|
|
|
Each of these roles can be assigned a specific foreground and
|
|
|
|
|
background color, from the following list:
|
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``black``
|
|
|
|
|
* ``red``
|
|
|
|
|
* ``green``
|
|
|
|
|
* ``yellow``
|
|
|
|
|
* ``blue``
|
|
|
|
|
* ``magenta``
|
|
|
|
|
* ``cyan``
|
|
|
|
|
* ``white``
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
|
|
|
|
Each of these colors can then be modified by using the following
|
|
|
|
|
display options:
|
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``bold``
|
|
|
|
|
* ``underscore``
|
|
|
|
|
* ``blink``
|
|
|
|
|
* ``reverse``
|
|
|
|
|
* ``conceal``
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
2011-02-14 23:18:30 +00:00
|
|
|
|
A color specification follows one of the following patterns:
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* ``role=fg``
|
|
|
|
|
* ``role=fg/bg``
|
|
|
|
|
* ``role=fg,option,option``
|
|
|
|
|
* ``role=fg/bg,option,option``
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
|
|
|
|
where ``role`` is the name of a valid color role, ``fg`` is the
|
|
|
|
|
foreground color, ``bg`` is the background color and each ``option``
|
|
|
|
|
is one of the color modifying options. Multiple color specifications
|
2015-05-07 23:41:42 +00:00
|
|
|
|
are then separated by a semicolon. For example::
|
2009-12-28 06:48:47 +00:00
|
|
|
|
|
|
|
|
|
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
|
|
|
|
|
|
|
|
|
|
would specify that errors be displayed using blinking yellow on blue,
|
|
|
|
|
and notices displayed using magenta. All other color roles would be
|
|
|
|
|
left uncolored.
|
|
|
|
|
|
|
|
|
|
Colors can also be specified by extending a base palette. If you put
|
|
|
|
|
a palette name in a color specification, all the colors implied by that
|
|
|
|
|
palette will be loaded. So::
|
|
|
|
|
|
|
|
|
|
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
|
|
|
|
|
|
|
|
|
|
would specify the use of all the colors in the light color palette,
|
|
|
|
|
*except* for the colors for errors and notices which would be
|
|
|
|
|
overridden as specified.
|
2006-05-02 01:31:56 +00:00
|
|
|
|
|
2014-08-05 12:23:34 +00:00
|
|
|
|
.. _ANSICON: http://adoxa.altervista.org/ansicon/
|
2013-12-03 02:11:59 +00:00
|
|
|
|
|
2006-05-02 01:31:56 +00:00
|
|
|
|
Bash completion
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
If you use the Bash shell, consider installing the Django bash completion
|
|
|
|
|
script, which lives in ``extras/django_bash_completion`` in the Django
|
2014-07-26 11:21:52 +00:00
|
|
|
|
distribution. It enables tab-completion of ``django-admin`` and
|
2006-05-02 01:31:56 +00:00
|
|
|
|
``manage.py`` commands, so you can, for instance...
|
|
|
|
|
|
2014-07-26 11:21:52 +00:00
|
|
|
|
* Type ``django-admin``.
|
2011-10-14 00:12:01 +00:00
|
|
|
|
* Press [TAB] to see all available options.
|
|
|
|
|
* Type ``sql``, then [TAB], to see all available options whose names start
|
|
|
|
|
with ``sql``.
|
2007-09-21 16:19:20 +00:00
|
|
|
|
|
2010-08-19 19:27:44 +00:00
|
|
|
|
See :doc:`/howto/custom-management-commands` for how to add customized actions.
|
2010-12-04 20:58:07 +00:00
|
|
|
|
|
|
|
|
|
==========================================
|
|
|
|
|
Running management commands from your code
|
|
|
|
|
==========================================
|
|
|
|
|
|
2012-03-02 17:13:53 +00:00
|
|
|
|
.. _call-command:
|
|
|
|
|
|
2010-12-04 20:58:07 +00:00
|
|
|
|
.. function:: django.core.management.call_command(name, *args, **options)
|
|
|
|
|
|
|
|
|
|
To call a management command from code use ``call_command``.
|
|
|
|
|
|
|
|
|
|
``name``
|
|
|
|
|
the name of the command to call.
|
|
|
|
|
|
|
|
|
|
``*args``
|
|
|
|
|
a list of arguments accepted by the command.
|
|
|
|
|
|
|
|
|
|
``**options``
|
|
|
|
|
named options accepted on the command-line.
|
|
|
|
|
|
|
|
|
|
Examples::
|
|
|
|
|
|
|
|
|
|
from django.core import management
|
|
|
|
|
management.call_command('flush', verbosity=0, interactive=False)
|
|
|
|
|
management.call_command('loaddata', 'test_data', verbosity=0)
|
2012-11-07 17:31:14 +00:00
|
|
|
|
|
2013-09-10 12:39:51 +00:00
|
|
|
|
Note that command options that take no arguments are passed as keywords
|
2014-08-09 19:03:19 +00:00
|
|
|
|
with ``True`` or ``False``, as you can see with the ``interactive`` option above.
|
2013-09-10 12:39:51 +00:00
|
|
|
|
|
2014-08-09 19:03:19 +00:00
|
|
|
|
Named arguments can be passed by using either one of the following syntaxes::
|
|
|
|
|
|
|
|
|
|
# Similar to the command line
|
2015-01-18 01:14:45 +00:00
|
|
|
|
management.call_command('dumpdata', '--natural-foreign')
|
2014-08-09 19:03:19 +00:00
|
|
|
|
|
|
|
|
|
# Named argument similar to the command line minus the initial dashes and
|
|
|
|
|
# with internal dashes replaced by underscores
|
2015-01-18 01:14:45 +00:00
|
|
|
|
management.call_command('dumpdata', natural_foreign=True)
|
2014-08-09 19:03:19 +00:00
|
|
|
|
|
2015-01-18 01:14:45 +00:00
|
|
|
|
# `use_natural_foreign_keys` is the option destination variable
|
|
|
|
|
management.call_command('dumpdata', use_natural_foreign_keys=True)
|
2013-09-10 12:39:51 +00:00
|
|
|
|
|
2014-08-09 19:03:19 +00:00
|
|
|
|
.. versionchanged:: 1.8
|
|
|
|
|
|
|
|
|
|
The first syntax is now supported thanks to management commands using the
|
|
|
|
|
:py:mod:`argparse` module. For the second syntax, Django previously passed
|
|
|
|
|
the option name as-is to the command, now it is always using the ``dest``
|
|
|
|
|
variable name (which may or may not be the same as the option name).
|
|
|
|
|
|
2013-09-10 12:39:51 +00:00
|
|
|
|
Command options which take multiple options are passed a list::
|
|
|
|
|
|
|
|
|
|
management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
|
|
|
|
|
|
2012-11-07 17:31:14 +00:00
|
|
|
|
Output redirection
|
|
|
|
|
==================
|
|
|
|
|
|
|
|
|
|
Note that you can redirect standard output and error streams as all commands
|
|
|
|
|
support the ``stdout`` and ``stderr`` options. For example, you could write::
|
|
|
|
|
|
|
|
|
|
with open('/tmp/command_output') as f:
|
|
|
|
|
management.call_command('dumpdata', stdout=f)
|