[4.0.x] Updated man page for Django 4.0.6.
This commit is contained in:
parent
0dc9c016fa
commit
c73215272a
|
@ -1,6 +1,6 @@
|
|||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "DJANGO-ADMIN" "1" "September 20, 2021" "4.0" "Django"
|
||||
.TH "DJANGO-ADMIN" "1" "July 04, 2022" "4.0" "Django"
|
||||
.SH NAME
|
||||
django-admin \- Utility script for the Django web framework
|
||||
.
|
||||
|
@ -36,7 +36,7 @@ This document outlines all it can do.
|
|||
.sp
|
||||
In addition, \fBmanage.py\fP is automatically created in each Django project. It
|
||||
does the same thing as \fBdjango\-admin\fP but also sets the
|
||||
\fBDJANGO_SETTINGS_MODULE\fP environment variable so that it points to your
|
||||
\fI\%DJANGO_SETTINGS_MODULE\fP environment variable so that it points to your
|
||||
project\(aqs \fBsettings.py\fP file.
|
||||
.sp
|
||||
The \fBdjango\-admin\fP script should be on your system path if you installed
|
||||
|
@ -46,7 +46,7 @@ environment activated.
|
|||
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
|
||||
\fI\%DJANGO_SETTINGS_MODULE\fP or the \fI\%\-\-settings\fP command line
|
||||
option.
|
||||
.sp
|
||||
The command\-line examples throughout this document use \fBdjango\-admin\fP to
|
||||
|
@ -86,7 +86,7 @@ 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
|
||||
the package containing your models. For example, if your \fI\%INSTALLED_APPS\fP
|
||||
contains the string \fB\(aqmysite.blog\(aq\fP, the app name is \fBblog\fP\&.
|
||||
.SS Determining the version
|
||||
.INDENT 0.0
|
||||
|
@ -120,7 +120,7 @@ notification and debug information that \fBdjango\-admin\fP prints to the consol
|
|||
.B django\-admin check [app_label [app_label ...]]
|
||||
.UNINDENT
|
||||
.sp
|
||||
Uses the system check framework to inspect the entire
|
||||
Uses the \fI\%system check framework\fP to inspect the entire
|
||||
Django project for common problems.
|
||||
.sp
|
||||
By default, all apps will be checked. You can check a subset of apps by
|
||||
|
@ -141,7 +141,7 @@ django\-admin check auth admin myapp
|
|||
.UNINDENT
|
||||
.sp
|
||||
The system check framework performs many different types of checks that are
|
||||
categorized with tags\&. You can use these
|
||||
\fI\%categorized with tags\fP\&. You can use these
|
||||
tags to restrict the checks performed to just those in a particular category.
|
||||
For example, to perform only models and compatibility checks, run:
|
||||
.INDENT 0.0
|
||||
|
@ -188,7 +188,7 @@ 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 \fBcheck\fP command at a different settings
|
||||
module, either by setting the \fBDJANGO_SETTINGS_MODULE\fP environment
|
||||
module, either by setting the \fI\%DJANGO_SETTINGS_MODULE\fP environment
|
||||
variable, or by passing the \fB\-\-settings\fP option:
|
||||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
|
@ -218,7 +218,7 @@ status. Default is \fBERROR\fP\&.
|
|||
.UNINDENT
|
||||
.sp
|
||||
Compiles \fB\&.po\fP files created by \fI\%makemessages\fP to \fB\&.mo\fP files for
|
||||
use with the built\-in gettext support. See /topics/i18n/index\&.
|
||||
use with the built\-in gettext support. See \fI\%Internationalization and localization\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-locale LOCALE, \-l LOCALE
|
||||
|
@ -283,7 +283,7 @@ django\-admin compilemessages \-\-ignore=cache \-\-ignore=outdated/*/locale
|
|||
.UNINDENT
|
||||
.sp
|
||||
Creates the cache tables for use with the database cache backend using the
|
||||
information from your settings file. See /topics/cache for more
|
||||
information from your settings file. See \fI\%Django\(aqs cache framework\fP for more
|
||||
information.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -306,8 +306,8 @@ customize it or use the migrations framework.
|
|||
.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.
|
||||
\fI\%ENGINE\fP setting, with the connection parameters
|
||||
specified in your \fI\%USER\fP, \fI\%PASSWORD\fP, etc., settings.
|
||||
.INDENT 0.0
|
||||
.IP \(bu 2
|
||||
For PostgreSQL, this runs the \fBpsql\fP command\-line client.
|
||||
|
@ -372,8 +372,8 @@ $ django\-admin dbshell \-\- \-e "select user()"
|
|||
\fBNOTE:\fP
|
||||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
Be aware that not all options set in the \fBOPTIONS\fP part of your
|
||||
database configuration in \fBDATABASES\fP are passed to the
|
||||
Be aware that not all options set in the \fI\%OPTIONS\fP part of your
|
||||
database configuration in \fI\%DATABASES\fP are passed to the
|
||||
command\-line client, e.g. \fB\(aqisolation_level\(aq\fP\&.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
|
@ -387,8 +387,8 @@ Displays differences between the current settings file and Django\(aqs default
|
|||
settings (or another settings file specified by \fI\%\-\-default\fP).
|
||||
.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
|
||||
example, the default settings don\(aqt define \fI\%ROOT_URLCONF\fP, so
|
||||
\fI\%ROOT_URLCONF\fP is followed by \fB"###"\fP in the output of
|
||||
\fBdiffsettings\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -428,7 +428,7 @@ If no application name is provided, all installed applications will be dumped.
|
|||
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
|
||||
records to dump. If you\(aqre using a \fI\%custom manager\fP as
|
||||
the default manager and it filters some of the available records, not all of the
|
||||
objects will be dumped.
|
||||
.INDENT 0.0
|
||||
|
@ -444,7 +444,7 @@ or modified by a custom manager.
|
|||
.UNINDENT
|
||||
.sp
|
||||
Specifies the serialization format of the output. Defaults to JSON. Supported
|
||||
formats are listed in serialization\-formats\&.
|
||||
formats are listed in \fI\%Serialization formats\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-indent INDENT
|
||||
|
@ -489,7 +489,7 @@ Uses 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\(aqre dumping \fBcontrib.auth\fP \fBPermission\fP objects or
|
||||
\fBcontrib.contenttypes\fP \fBContentType\fP objects, you should probably use this
|
||||
flag. See the natural keys
|
||||
flag. See the \fI\%natural keys\fP
|
||||
documentation for more details on this and the next option.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -563,7 +563,7 @@ Specifies the database to flush. Defaults to \fBdefault\fP\&.
|
|||
.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
|
||||
\fI\%NAME\fP setting and outputs a Django model module (a \fBmodels.py\fP
|
||||
file) to standard output.
|
||||
.sp
|
||||
You may choose what tables or views to inspect by passing their names as
|
||||
|
@ -584,7 +584,7 @@ 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. The recognized fields may depend on apps listed in
|
||||
\fBINSTALLED_APPS\fP\&. For example, \fBdjango.contrib.postgres\fP adds
|
||||
\fI\%INSTALLED_APPS\fP\&. For example, \fI\%django.contrib.postgres\fP adds
|
||||
recognition for several PostgreSQL\-specific field types.
|
||||
.IP \(bu 2
|
||||
If the database column name is a Python reserved word (such as
|
||||
|
@ -603,7 +603,7 @@ customizations. In particular, you\(aqll need to rearrange models\(aq order, so
|
|||
models that refer to other models are ordered properly.
|
||||
.sp
|
||||
Django doesn\(aqt create database defaults when a
|
||||
\fBdefault\fP is specified on a model field.
|
||||
\fI\%default\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
|
||||
|
@ -611,7 +611,7 @@ By default, \fBinspectdb\fP creates unmanaged models. That is, \fBmanaged = Fals
|
|||
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 remove
|
||||
\fI\%managed\fP option to \fBTrue\fP (or remove
|
||||
it because \fBTrue\fP is its default value).
|
||||
.SS Database\-specific notes
|
||||
.SS Oracle
|
||||
|
@ -683,7 +683,7 @@ Specifies a single app to look for fixtures in rather than looking in all apps.
|
|||
.B \-\-format FORMAT
|
||||
.UNINDENT
|
||||
.sp
|
||||
Specifies the serialization format (e.g.,
|
||||
Specifies the \fI\%serialization format\fP (e.g.,
|
||||
\fBjson\fP or \fBxml\fP) for fixtures \fI\%read from stdin\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -704,7 +704,7 @@ Django will search in three locations for fixtures:
|
|||
.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
|
||||
In any directory named in the \fI\%FIXTURE_DIRS\fP setting
|
||||
.IP 3. 3
|
||||
In the literal path named by the fixture
|
||||
.UNINDENT
|
||||
|
@ -727,7 +727,7 @@ django\-admin loaddata mydata.json
|
|||
.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).
|
||||
\fI\%serializer\fP (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:
|
||||
|
@ -761,12 +761,12 @@ django\-admin loaddata foo/bar/mydata.json
|
|||
.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\&.
|
||||
\fI\%FIXTURE_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
|
||||
Model defined \fI\%save()\fP methods are not called, and
|
||||
any \fI\%pre_save\fP or
|
||||
\fI\%post_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
|
||||
|
@ -870,7 +870,7 @@ 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
|
||||
For example, if your \fI\%DATABASES\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.
|
||||
|
@ -890,7 +890,7 @@ django\-admin loaddata \-\-format=json \-
|
|||
.UNINDENT
|
||||
.sp
|
||||
When reading from \fBstdin\fP, the \fI\%\-\-format\fP option
|
||||
is required to specify the serialization format
|
||||
is required to specify the \fI\%serialization format\fP
|
||||
of the input (e.g., \fBjson\fP or \fBxml\fP).
|
||||
.sp
|
||||
Loading from \fBstdin\fP is useful with standard input and output redirections.
|
||||
|
@ -916,11 +916,11 @@ 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.
|
||||
the \fI\%i18n documentation\fP for details.
|
||||
.sp
|
||||
This command doesn\(aqt require configured settings. However, when settings aren\(aqt
|
||||
configured, the command can\(aqt ignore the \fBMEDIA_ROOT\fP and
|
||||
\fBSTATIC_ROOT\fP directories or include \fBLOCALE_PATHS\fP\&.
|
||||
configured, the command can\(aqt ignore the \fI\%MEDIA_ROOT\fP and
|
||||
\fI\%STATIC_ROOT\fP directories or include \fI\%LOCALE_PATHS\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-all, \-a
|
||||
|
@ -1092,7 +1092,7 @@ language files from being created.
|
|||
\fBSEE ALSO:\fP
|
||||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
See customizing\-makemessages for instructions on how to customize
|
||||
See \fI\%Customizing the makemessages command\fP for instructions on how to customize
|
||||
the keywords that \fI\%makemessages\fP passes to \fBxgettext\fP\&.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
|
@ -1104,7 +1104,7 @@ the keywords that \fI\%makemessages\fP passes to \fBxgettext\fP\&.
|
|||
.sp
|
||||
Creates new migrations based on the changes detected to your models.
|
||||
Migrations, their relationship with apps and more are covered in depth in
|
||||
the migrations documentation\&.
|
||||
\fI\%the 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
|
||||
|
@ -1175,7 +1175,7 @@ history is skipped.
|
|||
.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
|
||||
the migrations documentation\&.
|
||||
\fI\%the migrations documentation\fP\&.
|
||||
.sp
|
||||
The behavior of this command changes depending on the arguments provided:
|
||||
.INDENT 0.0
|
||||
|
@ -1229,7 +1229,7 @@ run correctly.
|
|||
.sp
|
||||
Allows 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
|
||||
\fI\%CreateModel\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
|
||||
|
@ -1279,7 +1279,7 @@ 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.
|
||||
\fI\%WSGI_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
|
||||
|
@ -1340,12 +1340,12 @@ You can provide an IPv6 address surrounded by brackets
|
|||
.sp
|
||||
A hostname containing ASCII\-only characters can also be used.
|
||||
.sp
|
||||
If the staticfiles contrib app is enabled
|
||||
If the \fI\%staticfiles\fP contrib app is enabled
|
||||
(default in new projects) the \fI\%runserver\fP command will be overridden
|
||||
with its own runserver command.
|
||||
with its own \fI\%runserver\fP command.
|
||||
.sp
|
||||
Logging of each request and response of the server is sent to the
|
||||
django\-server\-logger logger.
|
||||
\fI\%django.server\fP logger.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-noreload
|
||||
|
@ -1483,9 +1483,9 @@ django\-admin runserver \-6 localhost:8000
|
|||
.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
|
||||
(such as CSS files, images, things under \fI\%MEDIA_URL\fP and so forth). If
|
||||
you want to configure Django to serve static media, read
|
||||
/howto/static\-files/index\&.
|
||||
\fI\%How to manage static files (e.g. images, JavaScript, CSS)\fP\&.
|
||||
.SS \fBsendtestemail\fP
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -1512,15 +1512,15 @@ together:
|
|||
.B \-\-managers
|
||||
.UNINDENT
|
||||
.sp
|
||||
Mails the email addresses specified in \fBMANAGERS\fP using
|
||||
\fBmail_managers()\fP\&.
|
||||
Mails the email addresses specified in \fI\%MANAGERS\fP using
|
||||
\fI\%mail_managers()\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-admins
|
||||
.UNINDENT
|
||||
.sp
|
||||
Mails the email addresses specified in \fBADMINS\fP using
|
||||
\fBmail_admins()\fP\&.
|
||||
Mails the email addresses specified in \fI\%ADMINS\fP using
|
||||
\fI\%mail_admins()\fP\&.
|
||||
.SS \fBshell\fP
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -1718,12 +1718,12 @@ Specifies the database for which to print the SQL. Defaults to \fBdefault\fP\&.
|
|||
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\&.
|
||||
please read \fI\%Squashing migrations\fP\&.
|
||||
.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.
|
||||
squashing limitation of \fI\%RunPython\fP and
|
||||
\fI\%django.db.migrations.operations.RunSQL\fP migration operations.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-no\-optimize
|
||||
|
@ -1846,7 +1846,7 @@ Specifies which directories in the app template should be excluded, in addition
|
|||
to \fB\&.git\fP and \fB__pycache__\fP\&. If this option is not provided, directories
|
||||
named \fB__pycache__\fP or starting with \fB\&.\fP will be excluded.
|
||||
.sp
|
||||
The \fBtemplate context\fP used for all matching
|
||||
The \fI\%template context\fP used for all matching
|
||||
files is:
|
||||
.INDENT 0.0
|
||||
.IP \(bu 2
|
||||
|
@ -1873,7 +1873,7 @@ 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
|
||||
To work around this problem, you can use the \fI\%templatetag\fP
|
||||
template tag to "escape" the various parts of the template syntax.
|
||||
.sp
|
||||
In addition, to allow Python template files that contain Django template
|
||||
|
@ -1947,7 +1947,7 @@ Specifies which directories in the project template should be excluded, in
|
|||
addition to \fB\&.git\fP and \fB__pycache__\fP\&. If this option is not provided,
|
||||
directories named \fB__pycache__\fP or starting with \fB\&.\fP will be excluded.
|
||||
.sp
|
||||
The \fBtemplate context\fP used is:
|
||||
The \fI\%template context\fP used is:
|
||||
.INDENT 0.0
|
||||
.IP \(bu 2
|
||||
Any option passed to the \fBstartproject\fP command (among the command\(aqs
|
||||
|
@ -1957,7 +1957,7 @@ supported options)
|
|||
.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
|
||||
\fBsecret_key\fP \-\- a random key for the \fI\%SECRET_KEY\fP setting
|
||||
.IP \(bu 2
|
||||
\fBdocs_version\fP \-\- the version of the documentation: \fB\(aqdev\(aq\fP or \fB\(aq1.x\(aq\fP
|
||||
.IP \(bu 2
|
||||
|
@ -1972,7 +1972,7 @@ for \fI\%startapp\fP\&.
|
|||
.B django\-admin test [test_label [test_label ...]]
|
||||
.UNINDENT
|
||||
.sp
|
||||
Runs tests for all installed apps. See /topics/testing/index for more
|
||||
Runs tests for all installed apps. See \fI\%Testing in Django\fP for more
|
||||
information.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -1986,7 +1986,7 @@ Stops running tests and reports the failure immediately after a test fails.
|
|||
.UNINDENT
|
||||
.sp
|
||||
Controls the test runner class that is used to execute tests. This value
|
||||
overrides the value provided by the \fBTEST_RUNNER\fP setting.
|
||||
overrides the value provided by the \fI\%TEST_RUNNER\fP setting.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-noinput, \-\-no\-input
|
||||
|
@ -1998,7 +1998,7 @@ existing test database.
|
|||
.sp
|
||||
The \fBtest\fP command receives options on behalf of the specified
|
||||
\fI\%\-\-testrunner\fP\&. These are the options of the default test runner:
|
||||
\fBDiscoverRunner\fP\&.
|
||||
\fI\%DiscoverRunner\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-keepdb
|
||||
|
@ -2008,7 +2008,7 @@ Preserves 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. Unless the \fBMIGRATE\fP test setting is
|
||||
subsequent run. Unless the \fI\%MIGRATE\fP test setting is
|
||||
\fBFalse\fP, any unapplied migrations will also be applied to the test database
|
||||
before running the test suite.
|
||||
.INDENT 0.0
|
||||
|
@ -2023,7 +2023,7 @@ that aren\(aqt properly isolated. The test order generated by this option is a
|
|||
deterministic function of the integer seed given. When no seed is passed, a
|
||||
seed is chosen randomly and printed to the console. To repeat a particular test
|
||||
order, pass a seed. The test orders generated by this option preserve Django\(aqs
|
||||
guarantees on test order\&. They also keep tests grouped
|
||||
\fI\%guarantees on test order\fP\&. They also keep tests grouped
|
||||
by test case class.
|
||||
.sp
|
||||
The shuffled orderings also have a special consistency property useful when
|
||||
|
@ -2037,22 +2037,22 @@ order of the original tests will be the same in the new order.
|
|||
.UNINDENT
|
||||
.sp
|
||||
Sorts test cases in the opposite execution 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. This can be used
|
||||
the side effects of tests that aren\(aqt properly isolated. \fI\%Grouping by test
|
||||
class\fP is preserved when using this option. This can be used
|
||||
in conjunction with \fB\-\-shuffle\fP to reverse the order for a particular seed.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-debug\-mode
|
||||
.UNINDENT
|
||||
.sp
|
||||
Sets the \fBDEBUG\fP setting to \fBTrue\fP prior to running tests. This may
|
||||
Sets the \fI\%DEBUG\fP setting to \fBTrue\fP prior to running tests. This may
|
||||
help troubleshoot test failures.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-debug\-sql, \-d
|
||||
.UNINDENT
|
||||
.sp
|
||||
Enables SQL logging for failing tests. If
|
||||
Enables \fI\%SQL logging\fP for failing tests. If
|
||||
\fB\-\-verbosity\fP is \fB2\fP, then queries in passing tests are also output.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -2084,8 +2084,8 @@ filesystem should create a temporary directory for their own use.
|
|||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
If you have test classes that cannot be run in parallel, you can use
|
||||
\fBSerializeMixin\fP to run them sequentially. See Enforce running test
|
||||
classes sequentially\&.
|
||||
\fBSerializeMixin\fP to run them sequentially. See \fI\%Enforce running test
|
||||
classes sequentially\fP\&.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.sp
|
||||
|
@ -2130,7 +2130,7 @@ Support for the value \fBauto\fP was added.
|
|||
.B \-\-tag TAGS
|
||||
.UNINDENT
|
||||
.sp
|
||||
Runs only tests marked with the specified tags\&.
|
||||
Runs only tests \fI\%marked with the specified tags\fP\&.
|
||||
May be specified multiple times and combined with \fI\%test \-\-exclude\-tag\fP\&.
|
||||
.sp
|
||||
Tests that fail to load are always considered matching.
|
||||
|
@ -2142,7 +2142,7 @@ In older versions, tests that failed to load did not match tags.
|
|||
.B \-\-exclude\-tag EXCLUDE_TAGS
|
||||
.UNINDENT
|
||||
.sp
|
||||
Excludes tests marked with the specified tags\&.
|
||||
Excludes tests \fI\%marked with the specified tags\fP\&.
|
||||
May be specified multiple times and combined with \fI\%test \-\-tag\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
@ -2207,7 +2207,7 @@ django\-admin testserver mydata.json
|
|||
\&...would perform the following steps:
|
||||
.INDENT 0.0
|
||||
.IP 1. 3
|
||||
Create a test database, as described in the\-test\-database\&.
|
||||
Create a test database, as described in \fI\%The test database\fP\&.
|
||||
.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.)
|
||||
|
@ -2219,7 +2219,7 @@ this newly created test database instead of your production database.
|
|||
This is useful in a number of ways:
|
||||
.INDENT 0.0
|
||||
.IP \(bu 2
|
||||
When you\(aqre writing unit tests of how your views
|
||||
When you\(aqre writing \fI\%unit 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
|
||||
|
@ -2284,8 +2284,8 @@ existing test database.
|
|||
.SH COMMANDS PROVIDED BY APPLICATIONS
|
||||
.sp
|
||||
Some commands are only available when the \fBdjango.contrib\fP application that
|
||||
implements them has been
|
||||
\fBenabled\fP\&. This section describes them grouped by
|
||||
\fI\%implements\fP them has been
|
||||
\fI\%enabled\fP\&. This section describes them grouped by
|
||||
their application.
|
||||
.SS \fBdjango.contrib.auth\fP
|
||||
.SS \fBchangepassword\fP
|
||||
|
@ -2294,7 +2294,7 @@ their application.
|
|||
.B django\-admin changepassword [<username>]
|
||||
.UNINDENT
|
||||
.sp
|
||||
This command is only available if Django\(aqs authentication system (\fBdjango.contrib.auth\fP) is installed.
|
||||
This command is only available if Django\(aqs \fI\%authentication 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
|
||||
|
@ -2328,7 +2328,7 @@ django\-admin changepassword ringo
|
|||
.B DJANGO_SUPERUSER_PASSWORD
|
||||
.UNINDENT
|
||||
.sp
|
||||
This command is only available if Django\(aqs authentication system (\fBdjango.contrib.auth\fP) is installed.
|
||||
This command is only available if Django\(aqs \fI\%authentication 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
|
||||
|
@ -2341,9 +2341,9 @@ variable. Otherwise, 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.
|
||||
.sp
|
||||
In non\-interactive mode, the
|
||||
\fBUSERNAME_FIELD\fP and required
|
||||
\fI\%USERNAME_FIELD\fP and required
|
||||
fields (listed in
|
||||
\fBREQUIRED_FIELDS\fP) fall back to
|
||||
\fI\%REQUIRED_FIELDS\fP) fall back to
|
||||
\fBDJANGO_SUPERUSER_<uppercase_field_name>\fP environment variables, unless they
|
||||
are overridden by a command line argument. For example, to provide an \fBemail\fP
|
||||
field, you can use \fBDJANGO_SUPERUSER_EMAIL\fP environment variable.
|
||||
|
@ -2378,7 +2378,7 @@ You can subclass the management command and override \fBget_input_data()\fP if y
|
|||
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
|
||||
\fI\%REQUIRED_FIELDS\fP and want to
|
||||
allow creating an instance instead of entering the primary key of an existing
|
||||
instance.
|
||||
.SS \fBdjango.contrib.contenttypes\fP
|
||||
|
@ -2388,7 +2388,7 @@ instance.
|
|||
.B django\-admin remove_stale_contenttypes
|
||||
.UNINDENT
|
||||
.sp
|
||||
This command is only available if Django\(aqs contenttypes app (\fBdjango.contrib.contenttypes\fP) is installed.
|
||||
This command is only available if Django\(aqs \fI\%contenttypes app\fP (\fI\%django.contrib.contenttypes\fP) is installed.
|
||||
.sp
|
||||
Deletes stale content types (from deleted models) in your database. Any objects
|
||||
that depend on the deleted content types will also be deleted. A list of
|
||||
|
@ -2406,14 +2406,14 @@ Specifies the database to use. Defaults to \fBdefault\fP\&.
|
|||
.UNINDENT
|
||||
.sp
|
||||
Deletes stale content types including ones from previously installed apps that
|
||||
have been removed from \fBINSTALLED_APPS\fP\&. Defaults to \fBFalse\fP\&.
|
||||
have been removed from \fI\%INSTALLED_APPS\fP\&. Defaults to \fBFalse\fP\&.
|
||||
.SS \fBdjango.contrib.gis\fP
|
||||
.SS \fBogrinspect\fP
|
||||
.sp
|
||||
This command is only available if GeoDjango
|
||||
This command is only available if \fI\%GeoDjango\fP
|
||||
(\fBdjango.contrib.gis\fP) is installed.
|
||||
.sp
|
||||
Please refer to its \fBdescription\fP in the GeoDjango
|
||||
Please refer to its \fI\%description\fP in the GeoDjango
|
||||
documentation.
|
||||
.SS \fBdjango.contrib.sessions\fP
|
||||
.SS \fBclearsessions\fP
|
||||
|
@ -2426,22 +2426,22 @@ Can be run as a cron job or directly to clean out expired sessions.
|
|||
.SS \fBdjango.contrib.sitemaps\fP
|
||||
.SS \fBping_google\fP
|
||||
.sp
|
||||
This command is only available if the Sitemaps framework (\fBdjango.contrib.sitemaps\fP) is installed.
|
||||
This command is only available if the \fI\%Sitemaps framework\fP (\fBdjango.contrib.sitemaps\fP) is installed.
|
||||
.sp
|
||||
Please refer to its \fBdescription\fP in the Sitemaps
|
||||
Please refer to its \fI\%description\fP in the Sitemaps
|
||||
documentation.
|
||||
.SS \fBdjango.contrib.staticfiles\fP
|
||||
.SS \fBcollectstatic\fP
|
||||
.sp
|
||||
This command is only available if the static files application (\fBdjango.contrib.staticfiles\fP) is installed.
|
||||
This command is only available if the \fI\%static files application\fP (\fBdjango.contrib.staticfiles\fP) is installed.
|
||||
.sp
|
||||
Please refer to its \fBdescription\fP in the
|
||||
staticfiles documentation.
|
||||
Please refer to its \fI\%description\fP in the
|
||||
\fI\%staticfiles\fP documentation.
|
||||
.SS \fBfindstatic\fP
|
||||
.sp
|
||||
This command is only available if the static files application (\fBdjango.contrib.staticfiles\fP) is installed.
|
||||
This command is only available if the \fI\%static files application\fP (\fBdjango.contrib.staticfiles\fP) is installed.
|
||||
.sp
|
||||
Please refer to its \fBdescription\fP in the staticfiles documentation.
|
||||
Please refer to its \fI\%description\fP in the \fI\%staticfiles\fP documentation.
|
||||
.SH DEFAULT OPTIONS
|
||||
.sp
|
||||
Although some commands may allow their own custom options, every command
|
||||
|
@ -2476,7 +2476,7 @@ django\-admin migrate \-\-pythonpath=\(aq/home/djangoprojects/myproject\(aq
|
|||
.sp
|
||||
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
|
||||
\fBdjango\-admin\fP will use the \fI\%DJANGO_SETTINGS_MODULE\fP environment
|
||||
variable.
|
||||
.sp
|
||||
This option is unnecessary in \fBmanage.py\fP, because it uses
|
||||
|
@ -2498,7 +2498,7 @@ django\-admin migrate \-\-settings=mysite.settings
|
|||
.B \-\-traceback
|
||||
.UNINDENT
|
||||
.sp
|
||||
Displays a full stack trace when a \fBCommandError\fP
|
||||
Displays a full stack trace when a \fI\%CommandError\fP
|
||||
is raised. By default, \fBdjango\-admin\fP will show an error message when a
|
||||
\fBCommandError\fP occurs and a full stack trace for any other exception.
|
||||
.sp
|
||||
|
@ -2581,7 +2581,7 @@ colored output to another command.
|
|||
.sp
|
||||
Skips running system checks prior to running the command. This option is only
|
||||
available if the
|
||||
\fBrequires_system_checks\fP command
|
||||
\fI\%requires_system_checks\fP command
|
||||
attribute is not an empty list or tuple.
|
||||
.sp
|
||||
Example usage:
|
||||
|
@ -2813,7 +2813,7 @@ Type \fBsql\fP, then [TAB], to see all available options whose names start
|
|||
with \fBsql\fP\&.
|
||||
.UNINDENT
|
||||
.sp
|
||||
See /howto/custom\-management\-commands for how to add customized actions.
|
||||
See \fI\%How to create custom django\-admin commands\fP for how to add customized actions.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B django.core.management.call_command(name, *args, **options)
|
||||
|
|
Loading…
Reference in New Issue