2419 lines
68 KiB
Groff
2419 lines
68 KiB
Groff
.\" Man page generated from reStructuredText.
|
||
.
|
||
.TH "DJANGO-ADMIN" "1" "September 23, 2015" "1.9" "Django"
|
||
.SH NAME
|
||
django-admin \- Utility script for the Django Web framework
|
||
.
|
||
.nr rst2man-indent-level 0
|
||
.
|
||
.de1 rstReportMargin
|
||
\\$1 \\n[an-margin]
|
||
level \\n[rst2man-indent-level]
|
||
level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||
-
|
||
\\n[rst2man-indent0]
|
||
\\n[rst2man-indent1]
|
||
\\n[rst2man-indent2]
|
||
..
|
||
.de1 INDENT
|
||
.\" .rstReportMargin pre:
|
||
. RS \\$1
|
||
. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
|
||
. nr rst2man-indent-level +1
|
||
.\" .rstReportMargin post:
|
||
..
|
||
.de UNINDENT
|
||
. RE
|
||
.\" indent \\n[an-margin]
|
||
.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||
.nr rst2man-indent-level -1
|
||
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
|
||
..
|
||
.sp
|
||
\fBdjango\-admin\fP is Django\(aqs command\-line utility for administrative tasks.
|
||
This document outlines all it can do.
|
||
.sp
|
||
In addition, \fBmanage.py\fP is automatically created in each Django project.
|
||
\fBmanage.py\fP is a thin wrapper around \fBdjango\-admin\fP that takes care of
|
||
several things for you before delegating to \fBdjango\-admin\fP:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
It puts your project\(aqs package on \fBsys.path\fP\&.
|
||
.IP \(bu 2
|
||
It sets the \fBDJANGO_SETTINGS_MODULE\fP environment variable so that
|
||
it points to your project\(aqs \fBsettings.py\fP file.
|
||
.IP \(bu 2
|
||
It calls \fBdjango.setup()\fP to initialize various internals of Django.
|
||
.UNINDENT
|
||
.sp
|
||
The \fBdjango\-admin\fP script should be on your system path if you installed
|
||
Django via its \fBsetup.py\fP utility. If it\(aqs not on your path, you can find it
|
||
in \fBsite\-packages/django/bin\fP within your Python installation. Consider
|
||
symlinking it from some place on your path, such as \fB/usr/local/bin\fP\&.
|
||
.sp
|
||
For Windows users, who do not have symlinking functionality available, you can
|
||
copy \fBdjango\-admin.exe\fP to a location on your existing path or edit the
|
||
\fBPATH\fP settings (under \fBSettings \- Control Panel \- System \- Advanced \-
|
||
Environment...\fP) to point to its installed location.
|
||
.sp
|
||
Generally, when working on a single Django project, it\(aqs easier to use
|
||
\fBmanage.py\fP than \fBdjango\-admin\fP\&. If you need to switch between multiple
|
||
Django settings files, use \fBdjango\-admin\fP with
|
||
\fBDJANGO_SETTINGS_MODULE\fP or the \fI\%\-\-settings\fP command line
|
||
option.
|
||
.sp
|
||
The command\-line examples throughout this document use \fBdjango\-admin\fP to
|
||
be consistent, but any example can use \fBmanage.py\fP or \fBpython \-m django\fP
|
||
just as well.
|
||
.sp
|
||
\fBpython \-m django\fP was added.
|
||
|
||
.SH USAGE
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
$ django\-admin <command> [options]
|
||
$ manage.py <command> [options]
|
||
$ python \-m django <command> [options]
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
\fBcommand\fP should be one of the commands listed in this document.
|
||
\fBoptions\fP, which is optional, should be zero or more of the options available
|
||
for the given command.
|
||
.SS Getting runtime help
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin help
|
||
.UNINDENT
|
||
.sp
|
||
Run \fBdjango\-admin help\fP to display usage information and a list of the
|
||
commands provided by each application.
|
||
.sp
|
||
Run \fBdjango\-admin help \-\-commands\fP to display a list of all available
|
||
commands.
|
||
.sp
|
||
Run \fBdjango\-admin help <command>\fP to display a description of the given
|
||
command and a list of its available options.
|
||
.SS App names
|
||
.sp
|
||
Many commands take a list of "app names." An "app name" is the basename of
|
||
the package containing your models. For example, if your \fBINSTALLED_APPS\fP
|
||
contains the string \fB\(aqmysite.blog\(aq\fP, the app name is \fBblog\fP\&.
|
||
.SS Determining the version
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin version
|
||
.UNINDENT
|
||
.sp
|
||
Run \fBdjango\-admin version\fP to display the current Django version.
|
||
.sp
|
||
The output follows the schema described in \fI\%PEP 386\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
1.4.dev17026
|
||
1.4a1
|
||
1.4
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS Displaying debug output
|
||
.sp
|
||
Use \fI\%\-\-verbosity\fP to specify the amount of notification and debug information
|
||
that \fBdjango\-admin\fP should print to the console. For more details, see the
|
||
documentation for the \fI\%\-\-verbosity\fP option.
|
||
.SH AVAILABLE COMMANDS
|
||
.SS check <appname appname ...>
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin check
|
||
.UNINDENT
|
||
.sp
|
||
Uses the \fBsystem check framework\fP to inspect
|
||
the entire Django project for common problems.
|
||
.sp
|
||
The system check framework will confirm that there aren\(aqt 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.
|
||
.sp
|
||
By default, all apps will be checked. You can check a subset of apps by providing
|
||
a list of app labels as arguments:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
python manage.py check auth admin myapp
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
If you do not specify any app, all apps will be checked.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-tag <tagname>
|
||
.UNINDENT
|
||
.sp
|
||
The \fBsystem check framework\fP 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:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
python manage.py check \-\-tag security \-\-tag compatibility
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-list\-tags
|
||
.UNINDENT
|
||
.sp
|
||
List all available tags.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-deploy
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-deploy\fP option activates some additional checks that are only relevant
|
||
in a deployment setting.
|
||
.sp
|
||
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 \fBcheck\fP command at a different settings
|
||
module, either by setting the \fBDJANGO_SETTINGS_MODULE\fP environment variable,
|
||
or by passing the \fB\-\-settings\fP option:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
python manage.py check \-\-deploy \-\-settings=production_settings
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Or you could run it directly on a production or staging deployment to verify
|
||
that the correct settings are in use (omitting \fB\-\-settings\fP). You could even
|
||
make it part of your integration test suite.
|
||
.SS compilemessages
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin compilemessages
|
||
.UNINDENT
|
||
.sp
|
||
Compiles .po files created by \fI\%makemessages\fP to .mo files for use with
|
||
the builtin gettext support. See \fB/topics/i18n/index\fP\&.
|
||
.sp
|
||
Use the \fI\%\-\-locale\fP option (or its shorter version \fB\-l\fP) to
|
||
specify the locale(s) to process. If not provided, all locales are processed.
|
||
.sp
|
||
Use the \fI\%\-\-exclude\fP option (or its shorter version \fB\-x\fP) to
|
||
specify the locale(s) to exclude from processing. If not provided, no locales
|
||
are excluded.
|
||
.sp
|
||
You can pass \fB\-\-use\-fuzzy\fP option (or \fB\-f\fP) to include fuzzy translations
|
||
into compiled files.
|
||
.sp
|
||
\fBcompilemessages\fP now matches the operation of \fI\%makemessages\fP,
|
||
scanning the project tree for \fB\&.po\fP files to compile.
|
||
|
||
.sp
|
||
Added \fB\-\-exclude\fP and \fB\-\-use\-fuzzy\fP options.
|
||
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin compilemessages \-\-locale=pt_BR
|
||
django\-admin compilemessages \-\-locale=pt_BR \-\-locale=fr \-f
|
||
django\-admin compilemessages \-l pt_BR
|
||
django\-admin compilemessages \-l pt_BR \-l fr \-\-use\-fuzzy
|
||
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
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS createcachetable
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin createcachetable
|
||
.UNINDENT
|
||
.sp
|
||
Creates the cache tables for use with the database cache backend using the
|
||
information from your settings file. See \fB/topics/cache\fP for more
|
||
information.
|
||
.sp
|
||
The \fI\%\-\-database\fP option can be used to specify the database
|
||
onto which the cache table will be installed, but since this information is
|
||
pulled from your settings by default, it\(aqs typically not needed.
|
||
.sp
|
||
The \fI\%\-\-dry\-run\fP option will print the SQL that would be run without
|
||
actually running it, so you can customize it or use the migrations framework.
|
||
.sp
|
||
The \fB\-\-dry\-run\fP option was added.
|
||
|
||
.SS dbshell
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin dbshell
|
||
.UNINDENT
|
||
.sp
|
||
Runs the command\-line client for the database engine specified in your
|
||
\fBENGINE\fP setting, with the connection parameters specified in your
|
||
\fBUSER\fP, \fBPASSWORD\fP, etc., settings.
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
For PostgreSQL, this runs the \fBpsql\fP command\-line client.
|
||
.IP \(bu 2
|
||
For MySQL, this runs the \fBmysql\fP command\-line client.
|
||
.IP \(bu 2
|
||
For SQLite, this runs the \fBsqlite3\fP command\-line client.
|
||
.IP \(bu 2
|
||
For Oracle, this runs the \fBsqlplus\fP command\-line client.
|
||
.UNINDENT
|
||
.sp
|
||
This command assumes the programs are on your \fBPATH\fP so that a simple call to
|
||
the program name (\fBpsql\fP, \fBmysql\fP, \fBsqlite3\fP, \fBsqlplus\fP) will find the
|
||
program in the right place. There\(aqs no way to specify the location of the
|
||
program manually.
|
||
.sp
|
||
The \fI\%\-\-database\fP option can be used to specify the database
|
||
onto which to open a shell.
|
||
.SS diffsettings
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin diffsettings
|
||
.UNINDENT
|
||
.sp
|
||
Displays differences between the current settings file and Django\(aqs default
|
||
settings.
|
||
.sp
|
||
Settings that don\(aqt appear in the defaults are followed by \fB"###"\fP\&. For
|
||
example, the default settings don\(aqt define \fBROOT_URLCONF\fP, so
|
||
\fBROOT_URLCONF\fP is followed by \fB"###"\fP in the output of
|
||
\fBdiffsettings\fP\&.
|
||
.sp
|
||
The \fI\%\-\-all\fP option may be provided to display all settings, even
|
||
if they have Django\(aqs default value. Such settings are prefixed by \fB"###"\fP\&.
|
||
.SS dumpdata <app_label app_label app_label.Model ...>
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin dumpdata
|
||
.UNINDENT
|
||
.sp
|
||
Outputs to standard output all data in the database associated with the named
|
||
application(s).
|
||
.sp
|
||
If no application name is provided, all installed applications will be dumped.
|
||
.sp
|
||
The output of \fBdumpdata\fP can be used as input for \fI\%loaddata\fP\&.
|
||
.sp
|
||
Note that \fBdumpdata\fP uses the default manager on the model for selecting the
|
||
records to dump. If you\(aqre using a custom manager as
|
||
the default manager and it filters some of the available records, not all of the
|
||
objects will be dumped.
|
||
.sp
|
||
The \fI\%\-\-all\fP option may be provided to specify that
|
||
\fBdumpdata\fP should use Django\(aqs base manager, dumping records which
|
||
might otherwise be filtered or modified by a custom manager.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-format <fmt>
|
||
.UNINDENT
|
||
.sp
|
||
By default, \fBdumpdata\fP will format its output in JSON, but you can use the
|
||
\fB\-\-format\fP option to specify another format. Currently supported formats
|
||
are listed in serialization\-formats\&.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-indent <num>
|
||
.UNINDENT
|
||
.sp
|
||
By default, \fBdumpdata\fP will output all data on a single line. This isn\(aqt
|
||
easy for humans to read, so you can use the \fB\-\-indent\fP option to
|
||
pretty\-print the output with a number of indentation spaces.
|
||
.sp
|
||
The \fI\%\-\-exclude\fP option may be provided to prevent specific
|
||
applications or models (specified as in the form of \fBapp_label.ModelName\fP)
|
||
from being dumped. If you specify a model name to \fBdumpdata\fP, the dumped
|
||
output will be restricted to that model, rather than the entire application.
|
||
You can also mix application names and model names.
|
||
.sp
|
||
The \fI\%\-\-database\fP option can be used to specify the database
|
||
from which data will be dumped.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-natural\-foreign
|
||
.UNINDENT
|
||
.sp
|
||
When this option is specified, Django will use the \fBnatural_key()\fP 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 \fBcontrib.auth\fP
|
||
\fBPermission\fP objects or \fBcontrib.contenttypes\fP \fBContentType\fP objects, you
|
||
should probably be using this flag. See the natural keys documentation for more details on this
|
||
and the next option.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-natural\-primary
|
||
.UNINDENT
|
||
.sp
|
||
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.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-pks
|
||
.UNINDENT
|
||
.sp
|
||
By default, \fBdumpdata\fP will output all the records of the model, but
|
||
you can use the \fB\-\-pks\fP option to specify a comma separated list of
|
||
primary keys on which to filter. This is only available when dumping
|
||
one model.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-output
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
By default \fBdumpdata\fP will output all the serialized data to standard output.
|
||
This option allows you to specify the file to which the data is to be written.
|
||
When this option is set and the verbosity is greater than 0 (the default), a
|
||
progress bar is shown in the terminal.
|
||
.sp
|
||
The progress bar in the terminal was added.
|
||
|
||
.SS flush
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin flush
|
||
.UNINDENT
|
||
.sp
|
||
Removes all data from the database and re\-executes any post\-synchronization
|
||
handlers. The table of which migrations have been applied is not cleared.
|
||
.sp
|
||
If you would rather start from an empty database and re\-run all migrations, you
|
||
should drop and recreate the database and then run \fI\%migrate\fP instead.
|
||
.sp
|
||
The \fI\%\-\-noinput\fP option may be provided to suppress all user
|
||
prompts.
|
||
.sp
|
||
The \fI\%\-\-database\fP option may be used to specify the database
|
||
to flush.
|
||
.SS inspectdb
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin inspectdb
|
||
.UNINDENT
|
||
.sp
|
||
Introspects the database tables in the database pointed\-to by the
|
||
\fBNAME\fP setting and outputs a Django model module (a \fBmodels.py\fP
|
||
file) to standard output.
|
||
.sp
|
||
Use this if you have a legacy database with which you\(aqd like to use Django.
|
||
The script will inspect the database and create a model for each table within
|
||
it.
|
||
.sp
|
||
As you might expect, the created models will have an attribute for every field
|
||
in the table. Note that \fBinspectdb\fP has a few special cases in its field\-name
|
||
output:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
If \fBinspectdb\fP cannot map a column\(aqs type to a model field type, it\(aqll
|
||
use \fBTextField\fP and will insert the Python comment
|
||
\fB\(aqThis field type is a guess.\(aq\fP next to the field in the generated
|
||
model.
|
||
.IP \(bu 2
|
||
If the database column name is a Python reserved word (such as
|
||
\fB\(aqpass\(aq\fP, \fB\(aqclass\(aq\fP or \fB\(aqfor\(aq\fP), \fBinspectdb\fP will append
|
||
\fB\(aq_field\(aq\fP to the attribute name. For example, if a table has a column
|
||
\fB\(aqfor\(aq\fP, the generated model will have a field \fB\(aqfor_field\(aq\fP, with
|
||
the \fBdb_column\fP attribute set to \fB\(aqfor\(aq\fP\&. \fBinspectdb\fP will insert
|
||
the Python comment
|
||
\fB\(aqField renamed because it was a Python reserved word.\(aq\fP next to the
|
||
field.
|
||
.UNINDENT
|
||
.sp
|
||
This feature is meant as a shortcut, not as definitive model generation. After
|
||
you run it, you\(aqll want to look over the generated models yourself to make
|
||
customizations. In particular, you\(aqll need to rearrange models\(aq order, so that
|
||
models that refer to other models are ordered properly.
|
||
.sp
|
||
Primary keys are automatically introspected for PostgreSQL, MySQL and
|
||
SQLite, in which case Django puts in the \fBprimary_key=True\fP where
|
||
needed.
|
||
.sp
|
||
\fBinspectdb\fP works with PostgreSQL, MySQL and SQLite. Foreign\-key detection
|
||
only works in PostgreSQL and with certain types of MySQL tables.
|
||
.sp
|
||
Django doesn\(aqt create database defaults when a
|
||
\fBdefault\fP is specified on a model field.
|
||
Similarly, database defaults aren\(aqt translated to model field defaults or
|
||
detected in any fashion by \fBinspectdb\fP\&.
|
||
.sp
|
||
By default, \fBinspectdb\fP creates unmanaged models. That is, \fBmanaged = False\fP
|
||
in the model\(aqs \fBMeta\fP class tells Django not to manage each table\(aqs creation,
|
||
modification, and deletion. If you do want to allow Django to manage the
|
||
table\(aqs lifecycle, you\(aqll need to change the
|
||
\fBmanaged\fP option to \fBTrue\fP (or simply remove
|
||
it because \fBTrue\fP is its default value).
|
||
.sp
|
||
The \fI\%\-\-database\fP option may be used to specify the
|
||
database to introspect.
|
||
.SS loaddata <fixture fixture ...>
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin loaddata
|
||
.UNINDENT
|
||
.sp
|
||
Searches for and loads the contents of the named fixture into the database.
|
||
.sp
|
||
The \fI\%\-\-database\fP option can be used to specify the database
|
||
onto which the data will be loaded.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-ignorenonexistent
|
||
.UNINDENT
|
||
.sp
|
||
The \fI\%\-\-ignorenonexistent\fP option can be used to ignore fields and
|
||
models that may have been removed since the fixture was originally generated.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-app
|
||
.UNINDENT
|
||
.sp
|
||
The \fI\%\-\-app\fP option can be used to specify a single app to look
|
||
for fixtures in rather than looking through all apps.
|
||
.sp
|
||
\fB\-\-ignorenonexistent\fP also ignores non\-existent models.
|
||
|
||
.SS What\(aqs a "fixture"?
|
||
.sp
|
||
A \fIfixture\fP 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.
|
||
.sp
|
||
Django will search in three locations for fixtures:
|
||
.INDENT 0.0
|
||
.IP 1. 3
|
||
In the \fBfixtures\fP directory of every installed application
|
||
.IP 2. 3
|
||
In any directory named in the \fBFIXTURE_DIRS\fP setting
|
||
.IP 3. 3
|
||
In the literal path named by the fixture
|
||
.UNINDENT
|
||
.sp
|
||
Django will load any and all fixtures it finds in these locations that match
|
||
the provided fixture names.
|
||
.sp
|
||
If the named fixture has a file extension, only fixtures of that type
|
||
will be loaded. For example:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin loaddata mydata.json
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
would only load JSON fixtures called \fBmydata\fP\&. The fixture extension
|
||
must correspond to the registered name of a
|
||
serializer (e.g., \fBjson\fP or \fBxml\fP).
|
||
.sp
|
||
If you omit the extensions, Django will search all available fixture types
|
||
for a matching fixture. For example:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin loaddata mydata
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
would look for any fixture of any fixture type called \fBmydata\fP\&. If a fixture
|
||
directory contained \fBmydata.json\fP, that fixture would be loaded
|
||
as a JSON fixture.
|
||
.sp
|
||
The fixtures that are named can include directory components. These
|
||
directories will be included in the search path. For example:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin loaddata foo/bar/mydata.json
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
would search \fB<app_label>/fixtures/foo/bar/mydata.json\fP for each installed
|
||
application, \fB<dirname>/foo/bar/mydata.json\fP for each directory in
|
||
\fBFIXTURE_DIRS\fP, and the literal path \fBfoo/bar/mydata.json\fP\&.
|
||
.sp
|
||
When fixture files are processed, the data is saved to the database as is.
|
||
Model defined \fBsave()\fP methods are not called, and
|
||
any \fBpre_save\fP or
|
||
\fBpost_save\fP signals will be called with
|
||
\fBraw=True\fP 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\(aqt present during fixture loading and would otherwise
|
||
raise an exception:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
from django.db.models.signals import post_save
|
||
from .models import MyModel
|
||
|
||
def my_handler(**kwargs):
|
||
# disable the handler during fixture loading
|
||
if kwargs[\(aqraw\(aq]:
|
||
return
|
||
...
|
||
|
||
post_save.connect(my_handler, sender=MyModel)
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
You could also write a simple decorator to encapsulate this logic:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
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[\(aqraw\(aq]:
|
||
return
|
||
signal_handler(*args, **kwargs)
|
||
return wrapper
|
||
|
||
@disable_for_loaddata
|
||
def my_handler(**kwargs):
|
||
...
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Just be aware that this logic will disable the signals whenever fixtures are
|
||
deserialized, not just during \fBloaddata\fP\&.
|
||
.sp
|
||
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.
|
||
.sp
|
||
The \fI\%dumpdata\fP command can be used to generate input for \fBloaddata\fP\&.
|
||
.SS Compressed fixtures
|
||
.sp
|
||
Fixtures may be compressed in \fBzip\fP, \fBgz\fP, or \fBbz2\fP format. For example:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin loaddata mydata.json
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
would look for any of \fBmydata.json\fP, \fBmydata.json.zip\fP,
|
||
\fBmydata.json.gz\fP, or \fBmydata.json.bz2\fP\&. The first file contained within a
|
||
zip\-compressed archive is used.
|
||
.sp
|
||
Note that if two fixtures with the same name but different
|
||
fixture type are discovered (for example, if \fBmydata.json\fP and
|
||
\fBmydata.xml.gz\fP were found in the same fixture directory), fixture
|
||
installation will be aborted, and any data installed in the call to
|
||
\fBloaddata\fP will be removed from the database.
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.IP "MySQL with MyISAM and fixtures"
|
||
.sp
|
||
The MyISAM storage engine of MySQL doesn\(aqt support transactions or
|
||
constraints, so if you use MyISAM, you won\(aqt get validation of fixture
|
||
data, or a rollback if multiple transaction files are found.
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS Database\-specific fixtures
|
||
.sp
|
||
If you\(aqre in a multi\-database setup, you might have fixture data that
|
||
you want to load onto one database, but not onto another. In this
|
||
situation, you can add a database identifier into the names of your fixtures.
|
||
.sp
|
||
For example, if your \fBDATABASES\fP setting has a \(aqmaster\(aq database
|
||
defined, name the fixture \fBmydata.master.json\fP or
|
||
\fBmydata.master.json.gz\fP and the fixture will only be loaded when you
|
||
specify you want to load data into the \fBmaster\fP database.
|
||
.SS makemessages
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin makemessages
|
||
.UNINDENT
|
||
.sp
|
||
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
|
||
conf/locale (in the Django tree) or locale (for project and application)
|
||
directory. After making changes to the messages files you need to compile them
|
||
with \fI\%compilemessages\fP for use with the builtin gettext support. See
|
||
the i18n documentation for details.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-all
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-all\fP or \fB\-a\fP option to update the message files for all
|
||
available languages.
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin makemessages \-\-all
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-extension
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-extension\fP or \fB\-e\fP option to specify a list of file extensions
|
||
to examine (default: ".html", ".txt").
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin makemessages \-\-locale=de \-\-extension xhtml
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Separate multiple extensions with commas or use \-e or \-\-extension multiple times:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin makemessages \-\-locale=de \-\-extension=html,txt \-\-extension xml
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fI\%\-\-locale\fP option (or its shorter version \fB\-l\fP) to
|
||
specify the locale(s) to process.
|
||
.sp
|
||
|
||
.sp
|
||
Use the \fI\%\-\-exclude\fP option (or its shorter version \fB\-x\fP) to
|
||
specify the locale(s) to exclude from processing. If not provided, no locales
|
||
are excluded.
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
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
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-domain
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-domain\fP or \fB\-d\fP option to change the domain of the messages files.
|
||
Currently supported:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
\fBdjango\fP for all \fB*.py\fP, \fB*.html\fP and \fB*.txt\fP files (default)
|
||
.IP \(bu 2
|
||
\fBdjangojs\fP for \fB*.js\fP files
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-symlinks
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-symlinks\fP or \fB\-s\fP option to follow symlinks to directories when
|
||
looking for new translation strings.
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin makemessages \-\-locale=de \-\-symlinks
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-ignore
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-ignore\fP or \fB\-i\fP option to ignore files or directories matching
|
||
the given \fI\%glob\fP\-style pattern. Use multiple times to ignore more.
|
||
.sp
|
||
These patterns are used by default: \fB\(aqCVS\(aq\fP, \fB\(aq.*\(aq\fP, \fB\(aq*~\(aq\fP, \fB\(aq*.pyc\(aq\fP
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin makemessages \-\-locale=en_US \-\-ignore=apps/* \-\-ignore=secret/*.html
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-no\-default\-ignore
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-no\-default\-ignore\fP option to disable the default values of
|
||
\fI\%\-\-ignore\fP\&.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-no\-wrap
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-no\-wrap\fP option to disable breaking long message lines into
|
||
several lines in language files.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-no\-location
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-no\-location\fP option to suppress writing \(aq\fB#: filename:line\fP’
|
||
comment lines in language files. Note that using this option makes it harder
|
||
for technically skilled translators to understand each message\(aqs context.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-keep\-pot
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-keep\-pot\fP option to prevent Django from deleting the temporary
|
||
.pot files it generates before creating the .po file. This is useful for
|
||
debugging errors which may prevent the final language files from being created.
|
||
.sp
|
||
\fBSEE ALSO:\fP
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
See customizing\-makemessages for instructions on how to customize
|
||
the keywords that \fI\%makemessages\fP passes to \fBxgettext\fP\&.
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS makemigrations [<app_label>]
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin makemigrations
|
||
.UNINDENT
|
||
.sp
|
||
Creates new migrations based on the changes detected to your models.
|
||
Migrations, their relationship with apps and more are covered in depth in
|
||
\fBthe migrations documentation\fP\&.
|
||
.sp
|
||
Providing one or more app names as arguments will limit the migrations created
|
||
to the app(s) specified and any dependencies needed (the table at the other end
|
||
of a \fBForeignKey\fP, for example).
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-noinput\fP 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.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-empty
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-empty\fP option will cause \fBmakemigrations\fP 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
|
||
the migration format, migration operations, and the dependencies between
|
||
your migrations.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-dry\-run
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-dry\-run\fP option shows what migrations would be made without
|
||
actually writing any migrations files to disk. Using this option along with
|
||
\fB\-\-verbosity 3\fP will also show the complete migrations files that would be
|
||
written.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-merge
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-merge\fP option enables fixing of migration conflicts.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-name, \-n
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-name\fP option allows you to give the migration(s) a custom name instead
|
||
of a generated one.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-exit, \-e
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-exit\fP option will cause \fBmakemigrations\fP to exit with error code 1
|
||
when no migrations are created (or would have been created, if combined with
|
||
\fB\-\-dry\-run\fP).
|
||
.SS migrate [<app_label> [<migrationname>]]
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin migrate
|
||
.UNINDENT
|
||
.sp
|
||
Synchronizes the database state with the current set of models and migrations.
|
||
Migrations, their relationship with apps and more are covered in depth in
|
||
\fBthe migrations documentation\fP\&.
|
||
.sp
|
||
The behavior of this command changes depending on the arguments provided:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
No arguments: All apps have all of their migrations run.
|
||
.IP \(bu 2
|
||
\fB<app_label>\fP: The specified app has its migrations run, up to the most
|
||
recent migration. This may involve running other apps\(aq migrations too, due
|
||
to dependencies.
|
||
.IP \(bu 2
|
||
\fB<app_label> <migrationname>\fP: 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 \fBzero\fP to unapply all
|
||
migrations for an app.
|
||
.UNINDENT
|
||
.sp
|
||
The \fI\%\-\-database\fP option can be used to specify the database to
|
||
migrate.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-fake
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-fake\fP option tells Django to mark the migrations as having been
|
||
applied or unapplied, but without actually running the SQL to change your
|
||
database schema.
|
||
.sp
|
||
This is intended for advanced users to manipulate the
|
||
current migration state directly if they\(aqre manually applying changes;
|
||
be warned that using \fB\-\-fake\fP runs the risk of putting the migration state
|
||
table into a state where manual recovery will be needed to make migrations
|
||
run correctly.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-fake\-initial
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-fake\-initial\fP option can be used to allow Django to skip an app\(aqs
|
||
initial migration if all database tables with the names of all models created
|
||
by all \fBCreateModel\fP 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.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-run\-syncdb
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-run\-syncdb\fP option allows creating tables for apps without migrations.
|
||
While this isn\(aqt recommended, the migrations framework is sometimes too slow
|
||
on large projects with hundreds of models.
|
||
.sp
|
||
Deprecated since version 1.8: The \fB\-\-list\fP option has been moved to the \fI\%showmigrations\fP
|
||
command.
|
||
|
||
.SS runserver [port or address:port]
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin runserver
|
||
.UNINDENT
|
||
.sp
|
||
Starts a lightweight development Web server on the local machine. By default,
|
||
the server runs on port 8000 on the IP address \fB127.0.0.1\fP\&. You can pass in an
|
||
IP address and port number explicitly.
|
||
.sp
|
||
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
|
||
are reserved for the superuser (root).
|
||
.sp
|
||
This server uses the WSGI application object specified by the
|
||
\fBWSGI_APPLICATION\fP setting.
|
||
.sp
|
||
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
|
||
security audits or performance tests. (And that\(aqs how it\(aqs gonna stay. We\(aqre 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.)
|
||
.sp
|
||
The development server automatically reloads Python code for each request, as
|
||
needed. You don\(aqt need to restart the server for code changes to take effect.
|
||
However, some actions like adding files don\(aqt trigger a restart, so you\(aqll
|
||
have to restart the server in these cases.
|
||
.sp
|
||
If you are using Linux and install \fI\%pyinotify\fP, 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.
|
||
.sp
|
||
When you start the server, and each time you change Python code while the
|
||
server is running, the system check framework will check your entire Django
|
||
project for some common errors (see the \fI\%check\fP command). If any
|
||
errors are found, they will be printed to standard output.
|
||
.sp
|
||
You can run as many concurrent servers as you want, as long as they\(aqre on
|
||
separate ports. Just execute \fBdjango\-admin runserver\fP more than once.
|
||
.sp
|
||
Note that the default IP address, \fB127.0.0.1\fP, is not accessible from other
|
||
machines on your network. To make your development server viewable to other
|
||
machines on the network, use its own IP address (e.g. \fB192.168.2.1\fP) or
|
||
\fB0.0.0.0\fP or \fB::\fP (with IPv6 enabled).
|
||
.sp
|
||
You can provide an IPv6 address surrounded by brackets
|
||
(e.g. \fB[200a::1]:8000\fP). This will automatically enable IPv6 support.
|
||
.sp
|
||
A hostname containing ASCII\-only characters can also be used.
|
||
.sp
|
||
If the \fBstaticfiles\fP contrib app is enabled
|
||
(default in new projects) the \fI\%runserver\fP command will be overridden
|
||
with its own runserver command.
|
||
.sp
|
||
If \fI\%migrate\fP was not previously executed, the table that stores the
|
||
history of migrations is created at first run of \fBrunserver\fP\&.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-noreload
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-noreload\fP option to disable the use of the auto\-reloader. This
|
||
means any Python code changes you make while the server is running will \fInot\fP
|
||
take effect if the particular Python modules have already been loaded into
|
||
memory.
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver \-\-noreload
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-nothreading
|
||
.UNINDENT
|
||
.sp
|
||
The development server is multithreaded by default. Use the \fB\-\-nothreading\fP
|
||
option to disable the use of threading in the development server.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-ipv6, \-6
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-ipv6\fP (or shorter \fB\-6\fP) option to tell Django to use IPv6 for
|
||
the development server. This changes the default IP address from
|
||
\fB127.0.0.1\fP to \fB::1\fP\&.
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver \-\-ipv6
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS Examples of using different ports and addresses
|
||
.sp
|
||
Port 8000 on IP address \fB127.0.0.1\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Port 8000 on IP address \fB1.2.3.4\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver 1.2.3.4:8000
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Port 7000 on IP address \fB127.0.0.1\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver 7000
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Port 7000 on IP address \fB1.2.3.4\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver 1.2.3.4:7000
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Port 8000 on IPv6 address \fB::1\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver \-6
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Port 7000 on IPv6 address \fB::1\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver \-6 7000
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Port 7000 on IPv6 address \fB2001:0db8:1234:5678::9\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver [2001:0db8:1234:5678::9]:7000
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Port 8000 on IPv4 address of host \fBlocalhost\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver localhost:8000
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Port 8000 on IPv6 address of host \fBlocalhost\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver \-6 localhost:8000
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS Serving static files with the development server
|
||
.sp
|
||
By default, the development server doesn\(aqt serve any static files for your site
|
||
(such as CSS files, images, things under \fBMEDIA_URL\fP and so forth). If
|
||
you want to configure Django to serve static media, read
|
||
\fB/howto/static\-files/index\fP\&.
|
||
.SS sendtestemail
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin sendtestemail
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
Sends a test email (to confirm email sending through Django is working) to the
|
||
recipient(s) specified. For example:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin sendtestemail foo@example.com bar@example.com
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-managers
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-managers\fP option to mail the email addresses specified in
|
||
\fBMANAGERS\fP using \fBmail_managers()\fP\&.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-admins
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-admins\fP option to mail the email addresses specified in
|
||
\fBADMINS\fP using \fBmail_admins()\fP\&.
|
||
.sp
|
||
Note that you may use any combination of these options together.
|
||
.SS shell
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin shell
|
||
.UNINDENT
|
||
.sp
|
||
Starts the Python interactive interpreter.
|
||
.sp
|
||
Django will use \fI\%IPython\fP or \fI\%bpython\fP if either is installed. If you have a
|
||
rich shell installed but want to force use of the "plain" Python interpreter,
|
||
use the \fB\-\-plain\fP option, like so:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin shell \-\-plain
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
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
|
||
with the \fB\-i\fP or \fB\-\-interface\fP options like so:
|
||
.sp
|
||
IPython:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin shell \-i ipython
|
||
django\-admin shell \-\-interface ipython
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
bpython:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin shell \-i bpython
|
||
django\-admin shell \-\-interface bpython
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
When the "plain" Python interactive interpreter starts (be it because
|
||
\fB\-\-plain\fP was specified or because no other interactive interface is
|
||
available) it reads the script pointed to by the \fI\%PYTHONSTARTUP\fP
|
||
environment variable and the \fB~/.pythonrc.py\fP script. If you don\(aqt wish this
|
||
behavior you can use the \fB\-\-no\-startup\fP option. e.g.:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin shell \-\-plain \-\-no\-startup
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS showmigrations [<app_label> [<app_label>]]
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin showmigrations
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
Shows all migrations in a project.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-list, \-l
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-list\fP option lists all of the apps Django knows about, the
|
||
migrations available for each app, and whether or not each migration is
|
||
applied (marked by an \fB[X]\fP next to the migration name).
|
||
.sp
|
||
Apps without migrations are also listed, but have \fB(no migrations)\fP printed
|
||
under them.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-plan, \-p
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-plan\fP 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 \fB\-\-list\fP, applied migrations are marked by an
|
||
\fB[X]\fP\&. For a verbosity of 2 and above, all dependencies of a migration will
|
||
also be shown.
|
||
.SS sqlflush
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin sqlflush
|
||
.UNINDENT
|
||
.sp
|
||
Prints the SQL statements that would be executed for the \fI\%flush\fP
|
||
command.
|
||
.sp
|
||
The \fI\%\-\-database\fP option can be used to specify the database for
|
||
which to print the SQL.
|
||
.SS sqlmigrate <app_label> <migrationname>
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin sqlmigrate
|
||
.UNINDENT
|
||
.sp
|
||
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.
|
||
.sp
|
||
Note that \fBsqlmigrate\fP doesn\(aqt colorize its output.
|
||
.sp
|
||
The \fI\%\-\-database\fP option can be used to specify the database for
|
||
which to generate the SQL.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-backwards
|
||
.UNINDENT
|
||
.sp
|
||
By default, the SQL created is for running the migration in the forwards
|
||
direction. Pass \fB\-\-backwards\fP to generate the SQL for
|
||
unapplying the migration instead.
|
||
.sp
|
||
To increase the readability of the overall SQL output the SQL code
|
||
generated for each migration operation is preceded by the operation\(aqs
|
||
description.
|
||
|
||
.SS sqlsequencereset <app_label app_label ...>
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin sqlsequencereset
|
||
.UNINDENT
|
||
.sp
|
||
Prints the SQL statements for resetting sequences for the given app name(s).
|
||
.sp
|
||
Sequences are indexes used by some database engines to track the next available
|
||
number for automatically incremented fields.
|
||
.sp
|
||
Use this command to generate SQL which will fix cases where a sequence is out
|
||
of sync with its automatically incremented field data.
|
||
.sp
|
||
The \fI\%\-\-database\fP option can be used to specify the database for
|
||
which to print the SQL.
|
||
.SS squashmigrations <app_label> [<start_migration_name>] <migration_name>
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin squashmigrations
|
||
.UNINDENT
|
||
.sp
|
||
Squashes the migrations for \fBapp_label\fP up to and including \fBmigration_name\fP
|
||
down into fewer migrations, if possible. The resulting squashed migrations
|
||
can live alongside the unsquashed ones safely. For more information,
|
||
please read migration\-squashing\&.
|
||
.sp
|
||
|
||
.sp
|
||
When \fBstart_migration_name\fP is given, Django will only include migrations
|
||
starting from and including this migration. This helps to mitigate the
|
||
squashing limitation of \fBRunPython\fP and
|
||
\fBdjango.db.migrations.operations.RunSQL\fP migration operations.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-no\-optimize
|
||
.UNINDENT
|
||
.sp
|
||
By default, Django will try to optimize the operations in your migrations
|
||
to reduce the size of the resulting file. Pass \fB\-\-no\-optimize\fP if this
|
||
process is failing for you or creating incorrect migrations, though please
|
||
also file a Django bug report about the behavior, as optimization is meant
|
||
to be safe.
|
||
.SS startapp <app_label> [destination]
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin startapp
|
||
.UNINDENT
|
||
.sp
|
||
Creates a Django app directory structure for the given app name in the current
|
||
directory or the given destination.
|
||
.sp
|
||
By default the directory created contains a \fBmodels.py\fP file and other app
|
||
template files. (See the \fI\%source\fP for more details.) If only the app
|
||
name is given, the app directory will be created in the current working
|
||
directory.
|
||
.sp
|
||
If the optional destination is provided, Django will use that existing
|
||
directory rather than creating a new one. You can use \(aq.\(aq to denote the current
|
||
working directory.
|
||
.sp
|
||
For example:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin startapp myapp /Users/jezdez/Code/myapp
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-template
|
||
.UNINDENT
|
||
.sp
|
||
With the \fB\-\-template\fP 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
|
||
compressed file (\fB\&.tar.gz\fP, \fB\&.tar.bz2\fP, \fB\&.tgz\fP, \fB\&.tbz\fP, \fB\&.zip\fP)
|
||
containing the app template files.
|
||
.sp
|
||
For example, this would look for an app template in the given directory when
|
||
creating the \fBmyapp\fP app:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin startapp \-\-template=/Users/jezdez/Code/my_app_template myapp
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Django will also accept URLs (\fBhttp\fP, \fBhttps\fP, \fBftp\fP) to compressed
|
||
archives with the app template files, downloading and extracting them on the
|
||
fly.
|
||
.sp
|
||
For example, taking advantage of GitHub\(aqs feature to expose repositories as
|
||
zip files, you can use a URL like:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin startapp \-\-template=https://github.com/githubuser/django\-app\-template/archive/master.zip myapp
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
When Django copies the app template files, it also renders certain files
|
||
through the template engine: the files whose extensions match the
|
||
\fB\-\-extension\fP option (\fBpy\fP by default) and the files whose names are passed
|
||
with the \fB\-\-name\fP option. The \fBtemplate context\fP used is:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
Any option passed to the \fBstartapp\fP command (among the command\(aqs supported
|
||
options)
|
||
.IP \(bu 2
|
||
\fBapp_name\fP \-\- the app name as passed to the command
|
||
.IP \(bu 2
|
||
\fBapp_directory\fP \-\- the full path of the newly created app
|
||
.IP \(bu 2
|
||
\fBcamel_case_app_name\fP \-\- the app name in camel case format
|
||
.IP \(bu 2
|
||
\fBdocs_version\fP \-\- the version of the documentation: \fB\(aqdev\(aq\fP or \fB\(aq1.x\(aq\fP
|
||
.UNINDENT
|
||
.sp
|
||
\fBcamel_case_app_name\fP was added.
|
||
|
||
.sp
|
||
\fBWARNING:\fP
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
When the app template files are rendered with the Django template
|
||
engine (by default all \fB*.py\fP 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
|
||
to template rendering, it might result in an incorrect example.
|
||
.sp
|
||
To work around this problem, you can use the \fBtemplatetag\fP
|
||
templatetag to "escape" the various parts of the template syntax.
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS startproject <projectname> [destination]
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin startproject
|
||
.UNINDENT
|
||
.sp
|
||
Creates a Django project directory structure for the given project name in
|
||
the current directory or the given destination.
|
||
.sp
|
||
By default, the new directory contains \fBmanage.py\fP and a project package
|
||
(containing a \fBsettings.py\fP and other files). See the \fI\%template source\fP for
|
||
details.
|
||
.sp
|
||
If only the project name is given, both the project directory and project
|
||
package will be named \fB<projectname>\fP and the project directory
|
||
will be created in the current working directory.
|
||
.sp
|
||
If the optional destination is provided, Django will use that existing
|
||
directory as the project directory, and create \fBmanage.py\fP and the project
|
||
package within it. Use \(aq.\(aq to denote the current working directory.
|
||
.sp
|
||
For example:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin startproject myproject /Users/jezdez/Code/myproject_repo
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
As with the \fI\%startapp\fP command, the \fB\-\-template\fP option lets you
|
||
specify a directory, file path or URL of a custom project template. See the
|
||
\fI\%startapp\fP documentation for details of supported project template
|
||
formats.
|
||
.sp
|
||
For example, this would look for a project template in the given directory
|
||
when creating the \fBmyproject\fP project:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin startproject \-\-template=/Users/jezdez/Code/my_project_template myproject
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Django will also accept URLs (\fBhttp\fP, \fBhttps\fP, \fBftp\fP) to compressed
|
||
archives with the project template files, downloading and extracting them on the
|
||
fly.
|
||
.sp
|
||
For example, taking advantage of GitHub\(aqs feature to expose repositories as
|
||
zip files, you can use a URL like:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin startproject \-\-template=https://github.com/githubuser/django\-project\-template/archive/master.zip myproject
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
When Django copies the project template files, it also renders certain files
|
||
through the template engine: the files whose extensions match the
|
||
\fB\-\-extension\fP option (\fBpy\fP by default) and the files whose names are passed
|
||
with the \fB\-\-name\fP option. The \fBtemplate context\fP used is:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
Any option passed to the \fBstartproject\fP command (among the command\(aqs
|
||
supported options)
|
||
.IP \(bu 2
|
||
\fBproject_name\fP \-\- the project name as passed to the command
|
||
.IP \(bu 2
|
||
\fBproject_directory\fP \-\- the full path of the newly created project
|
||
.IP \(bu 2
|
||
\fBsecret_key\fP \-\- a random key for the \fBSECRET_KEY\fP setting
|
||
.IP \(bu 2
|
||
\fBdocs_version\fP \-\- the version of the documentation: \fB\(aqdev\(aq\fP or \fB\(aq1.x\(aq\fP
|
||
.UNINDENT
|
||
.sp
|
||
Please also see the \fI\%rendering warning\fP as mentioned
|
||
for \fI\%startapp\fP\&.
|
||
.SS test <app or test identifier>
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin test
|
||
.UNINDENT
|
||
.sp
|
||
Runs tests for all installed models. See \fB/topics/testing/index\fP for more
|
||
information.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-failfast
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-failfast\fP option can be used to stop running tests and report the
|
||
failure immediately after a test fails.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-testrunner
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-testrunner\fP 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 \fBTEST_RUNNER\fP setting.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-liveserver
|
||
.UNINDENT
|
||
.sp
|
||
The \fB\-\-liveserver\fP option can be used to override the default address where
|
||
the live server (used with \fBLiveServerTestCase\fP) is
|
||
expected to run from. The default value is \fBlocalhost:8081\-8179\fP\&.
|
||
.sp
|
||
In earlier versions, the default value was \fBlocalhost:8081\fP\&.
|
||
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-keepdb
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-keepdb\fP option can be used to preserve the test database between test
|
||
runs. This has the advantage of skipping both the create and destroy actions
|
||
which can greatly decrease the time to run tests, especially those in a large
|
||
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.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-reverse
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-reverse\fP option can be used to sort test cases in the opposite order.
|
||
This may help in debugging the side effects of tests that aren\(aqt properly
|
||
isolated. Grouping by test class is preserved when using
|
||
this option.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-debug\-sql
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-debug\-sql\fP option can be used to enable SQL logging for failing tests. If \fI\%\-\-verbosity\fP is \fB2\fP,
|
||
then queries in passing tests are also output.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-parallel
|
||
.UNINDENT
|
||
.sp
|
||
|
||
.sp
|
||
The \fB\-\-parallel\fP option can be used to run tests in parallel in separate
|
||
processes. Since modern processors have multiple cores, this allows running
|
||
tests significantly faster.
|
||
.sp
|
||
By default \fB\-\-parallel\fP runs one process per core according to
|
||
\fI\%multiprocessing.cpu_count()\fP\&. You can adjust the number of processes
|
||
either by providing it as the option\(aqs value, e.g. \fB\-\-parallel=4\fP, or by
|
||
setting the \fBDJANGO_TEST_PROCESSES\fP environment variable.
|
||
.sp
|
||
Django distributes test cases — \fI\%unittest.TestCase\fP subclasses — to
|
||
subprocesses. If there are fewer test cases than configured processes, Django
|
||
will reduce the number of processes accordingly.
|
||
.sp
|
||
Each process gets its own database. You must ensure that different test cases
|
||
don\(aqt access the same resources. For instance, test cases that touch the
|
||
filesystem should create a temporary directory for their own use.
|
||
.sp
|
||
This option requires the third\-party \fBtblib\fP package to display tracebacks
|
||
correctly:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
$ pip install tblib
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
This feature isn\(aqt available on Windows. It doesn\(aqt work with the Oracle
|
||
database backend either.
|
||
.sp
|
||
\fBWARNING:\fP
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
When test parallelization is enabled and a test fails, Django may be
|
||
unable to display the exception traceback. This can make debugging
|
||
difficult. If you encounter this problem, run the affected test without
|
||
parallelization to see the traceback of the failure.
|
||
.sp
|
||
This is a known limitation. It arises from the need to serialize objects
|
||
in order to exchange them between processes. See
|
||
\fI\%What can be pickled and unpickled?\fP for details.
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS testserver <fixture fixture ...>
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin testserver
|
||
.UNINDENT
|
||
.sp
|
||
Runs a Django development server (as in \fI\%runserver\fP) using data from
|
||
the given fixture(s).
|
||
.sp
|
||
For example, this command:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin testserver mydata.json
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
\&...would perform the following steps:
|
||
.INDENT 0.0
|
||
.IP 1. 3
|
||
Create a test database, as described in the\-test\-database\&.
|
||
.IP 2. 3
|
||
Populate the test database with fixture data from the given fixtures.
|
||
(For more on fixtures, see the documentation for \fI\%loaddata\fP above.)
|
||
.IP 3. 3
|
||
Runs the Django development server (as in \fI\%runserver\fP), pointed at
|
||
this newly created test database instead of your production database.
|
||
.UNINDENT
|
||
.sp
|
||
This is useful in a number of ways:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
When you\(aqre writing \fBunit tests\fP of how your views
|
||
act with certain fixture data, you can use \fBtestserver\fP to interact with
|
||
the views in a Web browser, manually.
|
||
.IP \(bu 2
|
||
Let\(aqs say you\(aqre developing your Django application and have a "pristine"
|
||
copy of a database that you\(aqd like to interact with. You can dump your
|
||
database to a fixture (using the \fI\%dumpdata\fP command, explained
|
||
above), then use \fBtestserver\fP to run your Web application with that data.
|
||
With this arrangement, you have the flexibility of messing up your data
|
||
in any way, knowing that whatever data changes you\(aqre making are only
|
||
being made to a test database.
|
||
.UNINDENT
|
||
.sp
|
||
Note that this server does \fInot\fP automatically detect changes to your Python
|
||
source code (as \fI\%runserver\fP does). It does, however, detect changes to
|
||
templates.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-addrport [port number or ipaddr:port]
|
||
.UNINDENT
|
||
.sp
|
||
Use \fB\-\-addrport\fP to specify a different port, or IP address and port, from
|
||
the default of \fB127.0.0.1:8000\fP\&. This value follows exactly the same format and
|
||
serves exactly the same function as the argument to the \fI\%runserver\fP
|
||
command.
|
||
.sp
|
||
Examples:
|
||
.sp
|
||
To run the test server on port 7000 with \fBfixture1\fP and \fBfixture2\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin testserver \-\-addrport 7000 fixture1 fixture2
|
||
django\-admin testserver fixture1 fixture2 \-\-addrport 7000
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
(The above statements are equivalent. We include both of them to demonstrate
|
||
that it doesn\(aqt matter whether the options come before or after the fixture
|
||
arguments.)
|
||
.sp
|
||
To run on 1.2.3.4:7000 with a \fBtest\fP fixture:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin testserver \-\-addrport 1.2.3.4:7000 test
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
The \fI\%\-\-noinput\fP option may be provided to suppress all user
|
||
prompts.
|
||
.SH COMMANDS PROVIDED BY APPLICATIONS
|
||
.sp
|
||
Some commands are only available when the \fBdjango.contrib\fP application that
|
||
\fBimplements\fP them has been
|
||
\fBenabled\fP\&. This section describes them grouped by
|
||
their application.
|
||
.SS \fBdjango.contrib.auth\fP
|
||
.SS changepassword
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin changepassword
|
||
.UNINDENT
|
||
.sp
|
||
This command is only available if Django\(aqs \fBauthentication system\fP (\fBdjango.contrib.auth\fP) is installed.
|
||
.sp
|
||
Allows changing a user\(aqs 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.
|
||
.sp
|
||
Use the \fB\-\-database\fP option to specify the database to query for the user. If
|
||
it\(aqs not supplied, Django will use the \fBdefault\fP database.
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin changepassword ringo
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SS createsuperuser
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin createsuperuser
|
||
.UNINDENT
|
||
.sp
|
||
This command is only available if Django\(aqs \fBauthentication system\fP (\fBdjango.contrib.auth\fP) is installed.
|
||
.sp
|
||
Creates a superuser account (a user who has all permissions). This is
|
||
useful if you need to create an initial superuser account or if you need to
|
||
programmatically generate superuser accounts for your site(s).
|
||
.sp
|
||
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.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-username
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-email
|
||
.UNINDENT
|
||
.sp
|
||
The username and email address for the new account can be supplied by
|
||
using the \fB\-\-username\fP and \fB\-\-email\fP arguments on the command
|
||
line. If either of those is not supplied, \fBcreatesuperuser\fP will prompt for
|
||
it when running interactively.
|
||
.sp
|
||
Use the \fB\-\-database\fP option to specify the database into which the superuser
|
||
object will be saved.
|
||
.sp
|
||
|
||
.sp
|
||
You can subclass the management command and override \fBget_input_data()\fP if you
|
||
want to customize data input and validation. Consult the source code for
|
||
details on the existing implementation and the method\(aqs parameters. For example,
|
||
it could be useful if you have a \fBForeignKey\fP in
|
||
\fBREQUIRED_FIELDS\fP and want to
|
||
allow creating an instance instead of entering the primary key of an existing
|
||
instance.
|
||
.SS \fBdjango.contrib.gis\fP
|
||
.SS ogrinspect
|
||
.sp
|
||
This command is only available if \fBGeoDjango\fP
|
||
(\fBdjango.contrib.gis\fP) is installed.
|
||
.sp
|
||
Please refer to its \fBdescription\fP in the GeoDjango
|
||
documentation.
|
||
.SS \fBdjango.contrib.sessions\fP
|
||
.SS clearsessions
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django\-admin clearsessions
|
||
.UNINDENT
|
||
.sp
|
||
Can be run as a cron job or directly to clean out expired sessions.
|
||
.SS \fBdjango.contrib.sitemaps\fP
|
||
.SS ping_google
|
||
.sp
|
||
This command is only available if the \fBSitemaps framework\fP (\fBdjango.contrib.sitemaps\fP) is installed.
|
||
.sp
|
||
Please refer to its \fBdescription\fP in the Sitemaps
|
||
documentation.
|
||
.SS \fBdjango.contrib.staticfiles\fP
|
||
.SS collectstatic
|
||
.sp
|
||
This command is only available if the \fBstatic files application\fP (\fBdjango.contrib.staticfiles\fP) is installed.
|
||
.sp
|
||
Please refer to its \fBdescription\fP in the
|
||
\fBstaticfiles\fP documentation.
|
||
.SS findstatic
|
||
.sp
|
||
This command is only available if the \fBstatic files application\fP (\fBdjango.contrib.staticfiles\fP) is installed.
|
||
.sp
|
||
Please refer to its \fBdescription\fP in the \fBstaticfiles\fP documentation.
|
||
.SH DEFAULT OPTIONS
|
||
.sp
|
||
Although some commands may allow their own custom options, every command
|
||
allows for the following options:
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-pythonpath
|
||
.UNINDENT
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin migrate \-\-pythonpath=\(aq/home/djangoprojects/myproject\(aq
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Adds the given filesystem path to the Python \fI\%import search path\fP\&. If this
|
||
isn\(aqt provided, \fBdjango\-admin\fP will use the \fBPYTHONPATH\fP environment
|
||
variable.
|
||
.sp
|
||
Note that this option is unnecessary in \fBmanage.py\fP, because it takes care of
|
||
setting the Python path for you.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-settings
|
||
.UNINDENT
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin migrate \-\-settings=mysite.settings
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Explicitly specifies the settings module to use. The settings module should be
|
||
in Python package syntax, e.g. \fBmysite.settings\fP\&. If this isn\(aqt provided,
|
||
\fBdjango\-admin\fP will use the \fBDJANGO_SETTINGS_MODULE\fP environment
|
||
variable.
|
||
.sp
|
||
Note that this option is unnecessary in \fBmanage.py\fP, because it uses
|
||
\fBsettings.py\fP from the current project by default.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-traceback
|
||
.UNINDENT
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin migrate \-\-traceback
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
By default, \fBdjango\-admin\fP will show a simple error message whenever a
|
||
\fBCommandError\fP occurs, but a full stack trace
|
||
for any other exception. If you specify \fB\-\-traceback\fP, \fBdjango\-admin\fP
|
||
will also output a full stack trace when a \fBCommandError\fP is raised.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-verbosity
|
||
.UNINDENT
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin migrate \-\-verbosity 2
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Use \fB\-\-verbosity\fP to specify the amount of notification and debug information
|
||
that \fBdjango\-admin\fP should print to the console.
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
\fB0\fP means no output.
|
||
.IP \(bu 2
|
||
\fB1\fP means normal output (default).
|
||
.IP \(bu 2
|
||
\fB2\fP means verbose output.
|
||
.IP \(bu 2
|
||
\fB3\fP means \fIvery\fP verbose output.
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-no\-color
|
||
.UNINDENT
|
||
.sp
|
||
Example usage:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin runserver \-\-no\-color
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
By default, \fBdjango\-admin\fP will format the output to be colorized. For
|
||
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
|
||
\fB\-\-no\-color\fP option when running your command.
|
||
.SH COMMON OPTIONS
|
||
.sp
|
||
The following options are not available on every command, but they are common
|
||
to a number of commands.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-database
|
||
.UNINDENT
|
||
.sp
|
||
Used to specify the database on which a command will operate. If not
|
||
specified, this option will default to an alias of \fBdefault\fP\&.
|
||
.sp
|
||
For example, to dump data from the database with the alias \fBmaster\fP:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin dumpdata \-\-database=master
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-exclude
|
||
.UNINDENT
|
||
.sp
|
||
Exclude a specific application from the applications whose contents is
|
||
output. For example, to specifically exclude the \fBauth\fP application from
|
||
the output of dumpdata, you would call:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin dumpdata \-\-exclude=auth
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
If you want to exclude multiple applications, use multiple \fB\-\-exclude\fP
|
||
directives:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
django\-admin dumpdata \-\-exclude=auth \-\-exclude=contenttypes
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-locale
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-locale\fP or \fB\-l\fP option to specify the locale to process.
|
||
If not provided all locales are processed.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \-\-noinput
|
||
.UNINDENT
|
||
.sp
|
||
Use the \fB\-\-noinput\fP option to suppress all user prompting, such as "Are
|
||
you sure?" confirmation messages. This is useful if \fBdjango\-admin\fP is
|
||
being executed as an unattended, automated script. You can use \fB\-\-no\-input\fP
|
||
as an alias for this option.
|
||
.sp
|
||
The \fB\-\-no\-input\fP alias was added.
|
||
|
||
.SH EXTRA NICETIES
|
||
.SS Syntax coloring
|
||
.sp
|
||
The \fBdjango\-admin\fP / \fBmanage.py\fP commands will use pretty
|
||
color\-coded output if your terminal supports ANSI\-colored output. It
|
||
won\(aqt use the color codes if you\(aqre piping the command\(aqs output to
|
||
another program.
|
||
.sp
|
||
Under Windows, the native console doesn\(aqt support ANSI escape sequences so by
|
||
default there is no color output. But you can install the \fI\%ANSICON\fP
|
||
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.
|
||
.sp
|
||
The colors used for syntax highlighting can be customized. Django
|
||
ships with three color palettes:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
\fBdark\fP, suited to terminals that show white text on a black
|
||
background. This is the default palette.
|
||
.IP \(bu 2
|
||
\fBlight\fP, suited to terminals that show black text on a white
|
||
background.
|
||
.IP \(bu 2
|
||
\fBnocolor\fP, which disables syntax highlighting.
|
||
.UNINDENT
|
||
.sp
|
||
You select a palette by setting a \fBDJANGO_COLORS\fP environment
|
||
variable to specify the palette you want to use. For example, to
|
||
specify the \fBlight\fP palette under a Unix or OS/X BASH shell, you
|
||
would run the following at a command prompt:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
export DJANGO_COLORS="light"
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
You can also customize the colors that are used. Django specifies a
|
||
number of roles in which color is used:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
\fBerror\fP \- A major error.
|
||
.IP \(bu 2
|
||
\fBnotice\fP \- A minor error.
|
||
.IP \(bu 2
|
||
\fBsql_field\fP \- The name of a model field in SQL.
|
||
.IP \(bu 2
|
||
\fBsql_coltype\fP \- The type of a model field in SQL.
|
||
.IP \(bu 2
|
||
\fBsql_keyword\fP \- An SQL keyword.
|
||
.IP \(bu 2
|
||
\fBsql_table\fP \- The name of a model in SQL.
|
||
.IP \(bu 2
|
||
\fBhttp_info\fP \- A 1XX HTTP Informational server response.
|
||
.IP \(bu 2
|
||
\fBhttp_success\fP \- A 2XX HTTP Success server response.
|
||
.IP \(bu 2
|
||
\fBhttp_not_modified\fP \- A 304 HTTP Not Modified server response.
|
||
.IP \(bu 2
|
||
\fBhttp_redirect\fP \- A 3XX HTTP Redirect server response other than 304.
|
||
.IP \(bu 2
|
||
\fBhttp_not_found\fP \- A 404 HTTP Not Found server response.
|
||
.IP \(bu 2
|
||
\fBhttp_bad_request\fP \- A 4XX HTTP Bad Request server response other than 404.
|
||
.IP \(bu 2
|
||
\fBhttp_server_error\fP \- A 5XX HTTP Server Error response.
|
||
.UNINDENT
|
||
.sp
|
||
Each of these roles can be assigned a specific foreground and
|
||
background color, from the following list:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
\fBblack\fP
|
||
.IP \(bu 2
|
||
\fBred\fP
|
||
.IP \(bu 2
|
||
\fBgreen\fP
|
||
.IP \(bu 2
|
||
\fByellow\fP
|
||
.IP \(bu 2
|
||
\fBblue\fP
|
||
.IP \(bu 2
|
||
\fBmagenta\fP
|
||
.IP \(bu 2
|
||
\fBcyan\fP
|
||
.IP \(bu 2
|
||
\fBwhite\fP
|
||
.UNINDENT
|
||
.sp
|
||
Each of these colors can then be modified by using the following
|
||
display options:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
\fBbold\fP
|
||
.IP \(bu 2
|
||
\fBunderscore\fP
|
||
.IP \(bu 2
|
||
\fBblink\fP
|
||
.IP \(bu 2
|
||
\fBreverse\fP
|
||
.IP \(bu 2
|
||
\fBconceal\fP
|
||
.UNINDENT
|
||
.sp
|
||
A color specification follows one of the following patterns:
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
\fBrole=fg\fP
|
||
.IP \(bu 2
|
||
\fBrole=fg/bg\fP
|
||
.IP \(bu 2
|
||
\fBrole=fg,option,option\fP
|
||
.IP \(bu 2
|
||
\fBrole=fg/bg,option,option\fP
|
||
.UNINDENT
|
||
.sp
|
||
where \fBrole\fP is the name of a valid color role, \fBfg\fP is the
|
||
foreground color, \fBbg\fP is the background color and each \fBoption\fP
|
||
is one of the color modifying options. Multiple color specifications
|
||
are then separated by a semicolon. For example:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
would specify that errors be displayed using blinking yellow on blue,
|
||
and notices displayed using magenta. All other color roles would be
|
||
left uncolored.
|
||
.sp
|
||
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:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
would specify the use of all the colors in the light color palette,
|
||
\fIexcept\fP for the colors for errors and notices which would be
|
||
overridden as specified.
|
||
.SS Bash completion
|
||
.sp
|
||
If you use the Bash shell, consider installing the Django bash completion
|
||
script, which lives in \fBextras/django_bash_completion\fP in the Django
|
||
distribution. It enables tab\-completion of \fBdjango\-admin\fP and
|
||
\fBmanage.py\fP commands, so you can, for instance...
|
||
.INDENT 0.0
|
||
.IP \(bu 2
|
||
Type \fBdjango\-admin\fP\&.
|
||
.IP \(bu 2
|
||
Press [TAB] to see all available options.
|
||
.IP \(bu 2
|
||
Type \fBsql\fP, then [TAB], to see all available options whose names start
|
||
with \fBsql\fP\&.
|
||
.UNINDENT
|
||
.sp
|
||
See \fB/howto/custom\-management\-commands\fP for how to add customized actions.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B django.core.management.call_command(name, *args, **options)
|
||
.UNINDENT
|
||
.sp
|
||
To call a management command from code use \fBcall_command\fP\&.
|
||
.INDENT 0.0
|
||
.TP
|
||
.B \fBname\fP
|
||
the name of the command to call.
|
||
.TP
|
||
.B \fB*args\fP
|
||
a list of arguments accepted by the command.
|
||
.TP
|
||
.B \fB**options\fP
|
||
named options accepted on the command\-line.
|
||
.UNINDENT
|
||
.sp
|
||
Examples:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
from django.core import management
|
||
management.call_command(\(aqflush\(aq, verbosity=0, interactive=False)
|
||
management.call_command(\(aqloaddata\(aq, \(aqtest_data\(aq, verbosity=0)
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
Note that command options that take no arguments are passed as keywords
|
||
with \fBTrue\fP or \fBFalse\fP, as you can see with the \fBinteractive\fP option above.
|
||
.sp
|
||
Named arguments can be passed by using either one of the following syntaxes:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
# Similar to the command line
|
||
management.call_command(\(aqdumpdata\(aq, \(aq\-\-natural\-foreign\(aq)
|
||
|
||
# Named argument similar to the command line minus the initial dashes and
|
||
# with internal dashes replaced by underscores
|
||
management.call_command(\(aqdumpdata\(aq, natural_foreign=True)
|
||
|
||
# \(gause_natural_foreign_keys\(ga is the option destination variable
|
||
management.call_command(\(aqdumpdata\(aq, use_natural_foreign_keys=True)
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.sp
|
||
The first syntax is now supported thanks to management commands using the
|
||
\fI\%argparse\fP module. For the second syntax, Django previously passed
|
||
the option name as\-is to the command, now it is always using the \fBdest\fP
|
||
variable name (which may or may not be the same as the option name).
|
||
|
||
.sp
|
||
Command options which take multiple options are passed a list:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
management.call_command(\(aqdumpdata\(aq, exclude=[\(aqcontenttypes\(aq, \(aqauth\(aq])
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SH OUTPUT REDIRECTION
|
||
.sp
|
||
Note that you can redirect standard output and error streams as all commands
|
||
support the \fBstdout\fP and \fBstderr\fP options. For example, you could write:
|
||
.INDENT 0.0
|
||
.INDENT 3.5
|
||
.sp
|
||
.nf
|
||
.ft C
|
||
with open(\(aq/path/to/command_output\(aq) as f:
|
||
management.call_command(\(aqdumpdata\(aq, stdout=f)
|
||
.ft P
|
||
.fi
|
||
.UNINDENT
|
||
.UNINDENT
|
||
.SH AUTHOR
|
||
Django Software Foundation
|
||
.SH COPYRIGHT
|
||
Django Software Foundation and contributors
|
||
.\" Generated by docutils manpage writer.
|
||
.
|