mirror of https://github.com/django/django.git
Updated man page for Django 4.2 alpha.
This commit is contained in:
Mariusz Felisiak
parent
e734cccea0
commit
9409312eef
|
|
@ -1,8 +1,5 @@
|
|||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "DJANGO-ADMIN" "1" "May 17, 2022" "4.1" "Django"
|
||||
.SH NAME
|
||||
django-admin \- Utility script for the Django web framework
|
||||
.
|
||||
.nr rst2man-indent-level 0
|
||||
.
|
||||
|
|
@ -30,13 +27,16 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
|||
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||||
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
|
||||
..
|
||||
.TH "DJANGO-ADMIN" "1" "January 15, 2023" "4.2" "Django"
|
||||
.SH NAME
|
||||
django-admin \- Utility script for the Django web framework
|
||||
.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. 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
|
||||
|
|
@ -427,8 +427,13 @@ 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
|
||||
When result of \fBdumpdata\fP is saved as a file, it can serve as a
|
||||
\fI\%fixture\fP for
|
||||
\fI\%tests\fP or as an
|
||||
\fI\%initial data\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 +449,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 +494,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
|
||||
|
|
@ -561,7 +566,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
|
||||
|
|
@ -582,7 +587,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
|
||||
|
|
@ -601,7 +606,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
|
||||
|
|
@ -609,7 +614,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
|
||||
|
|
@ -655,7 +660,8 @@ If this option is provided, models are also created for database views.
|
|||
.B django\-admin loaddata fixture [fixture ...]
|
||||
.UNINDENT
|
||||
.sp
|
||||
Searches for and loads the contents of the named fixture into the database.
|
||||
Searches for and loads the contents of the named
|
||||
\fI\%fixture\fP into the database.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-database DATABASE
|
||||
|
|
@ -681,7 +687,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
|
||||
|
|
@ -691,184 +697,6 @@ Specifies the serialization format (e.g.,
|
|||
Excludes loading the fixtures from the given applications and/or models (in the
|
||||
form of \fBapp_label\fP or \fBapp_label.ModelName\fP). Use the option multiple
|
||||
times to exclude more than one app or model.
|
||||
.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 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, \fBbz2\fP, \fBlzma\fP, or \fBxz\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,
|
||||
\fBmydata.json.bz2\fP, \fBmydata.json.lzma\fP, or \fBmydata.json.xz\fP\&. The first
|
||||
file contained within a 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 \(aqusers\(aq database
|
||||
defined, name the fixture \fBmydata.users.json\fP or
|
||||
\fBmydata.users.json.gz\fP and the fixture will only be loaded when you
|
||||
specify you want to load data into the \fBusers\fP database.
|
||||
.SS Loading fixtures from \fBstdin\fP
|
||||
.sp
|
||||
You can use a dash as the fixture name to load input from \fBsys.stdin\fP\&. For
|
||||
|
|
@ -885,7 +713,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.
|
||||
|
|
@ -900,6 +728,15 @@ django\-admin dumpdata \-\-format=json \-\-database=test app_label.ModelName | d
|
|||
.fi
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.sp
|
||||
The \fI\%dumpdata\fP command can be used to generate input for \fBloaddata\fP\&.
|
||||
.sp
|
||||
\fBSEE ALSO:\fP
|
||||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
For more detail about fixtures see the \fI\%Fixtures\fP topic.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.SS \fBmakemessages\fP
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
|
@ -911,11 +748,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
|
||||
|
|
@ -1087,7 +924,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
|
||||
|
|
@ -1099,7 +936,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
|
||||
|
|
@ -1157,6 +994,10 @@ Generate migration files without Django version and timestamp header.
|
|||
.sp
|
||||
Makes \fBmakemigrations\fP exit with a non\-zero status when model changes without
|
||||
migrations are detected.
|
||||
.sp
|
||||
In older versions, the missing migrations were also created when using the
|
||||
\fB\-\-check\fP option.
|
||||
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-scriptable
|
||||
|
|
@ -1166,6 +1007,15 @@ migrations are detected.
|
|||
.sp
|
||||
Diverts log output and input prompts to \fBstderr\fP, writing only paths of
|
||||
generated migration files to \fBstdout\fP\&.
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-update
|
||||
.UNINDENT
|
||||
.sp
|
||||
|
||||
.sp
|
||||
Merges model changes into the latest migration and optimize the resulting
|
||||
operations.
|
||||
.SS \fBmigrate\fP
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
|
@ -1174,7 +1024,7 @@ generated migration files to \fBstdout\fP\&.
|
|||
.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
|
||||
|
|
@ -1228,7 +1078,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
|
||||
|
|
@ -1272,7 +1122,7 @@ detected.
|
|||
.sp
|
||||
Deletes nonexistent migrations from the \fBdjango_migrations\fP table. This is
|
||||
useful when migration files replaced by a squashed migration have been removed.
|
||||
See migration\-squashing for more details.
|
||||
See \fI\%Squashing migrations\fP for more details.
|
||||
.SS \fBoptimizemigration\fP
|
||||
.sp
|
||||
|
||||
|
|
@ -1307,7 +1157,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
|
||||
|
|
@ -1360,20 +1210,20 @@ separate ports by executing \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).
|
||||
machines on the network, use its own IP address (e.g. \fB192.168.2.1\fP), \fB0\fP
|
||||
(shortcut for \fB0.0.0.0\fP), \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 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
|
||||
|
|
@ -1396,9 +1246,6 @@ multithreaded by default.
|
|||
.sp
|
||||
Uses IPv6 for the development server. This changes the default IP address from
|
||||
\fB127.0.0.1\fP to \fB::1\fP\&.
|
||||
.sp
|
||||
Support for the \fB\-\-skip\-checks\fP option was added.
|
||||
|
||||
.SS Examples of using different ports and addresses
|
||||
.sp
|
||||
Port 8000 on IP address \fB127.0.0.1\fP:
|
||||
|
|
@ -1511,9 +1358,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
|
||||
|
|
@ -1540,15 +1387,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
|
||||
|
|
@ -1746,12 +1593,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
|
||||
|
|
@ -1867,14 +1714,12 @@ empty list.
|
|||
.TP
|
||||
.B \-\-exclude DIRECTORIES, \-x DIRECTORIES
|
||||
.UNINDENT
|
||||
.sp
|
||||
|
||||
.sp
|
||||
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
|
||||
|
|
@ -1901,7 +1746,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
|
||||
|
|
@ -1910,6 +1755,20 @@ byte\-compile invalid \fB*.py\fP files, template files ending with \fB\&.py\-tpl
|
|||
will be renamed to \fB\&.py\fP\&.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.sp
|
||||
\fBWARNING:\fP
|
||||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
The contents of custom app (or project) templates should always be
|
||||
audited before use: Such templates define code that will become
|
||||
part of your project, and this means that such code will be trusted
|
||||
as much as any app you install, or code you write yourself.
|
||||
Further, even rendering the templates is, effectively, executing
|
||||
code that was provided as input to the management command. The
|
||||
Django template language may provide wide access into the system,
|
||||
so make sure any custom template you use is worthy of your trust.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.SS \fBstartproject\fP
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
|
@ -1968,14 +1827,12 @@ empty list.
|
|||
.TP
|
||||
.B \-\-exclude DIRECTORIES, \-x DIRECTORIES
|
||||
.UNINDENT
|
||||
.sp
|
||||
|
||||
.sp
|
||||
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
|
||||
|
|
@ -1985,22 +1842,23 @@ 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
|
||||
\fBdjango_version\fP \-\- the version of Django, e.g. \fB\(aq2.0.3\(aq\fP
|
||||
.UNINDENT
|
||||
.sp
|
||||
Please also see the \fI\%rendering warning\fP as mentioned
|
||||
for \fI\%startapp\fP\&.
|
||||
Please also see the \fI\%rendering warning\fP and
|
||||
\fI\%trusted code warning\fP as mentioned for
|
||||
\fI\%startapp\fP\&.
|
||||
.SS \fBtest\fP
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.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
|
||||
|
|
@ -2014,7 +1872,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
|
||||
|
|
@ -2026,7 +1884,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
|
||||
|
|
@ -2036,22 +1894,20 @@ 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
|
||||
.TP
|
||||
.B \-\-shuffle [SEED]
|
||||
.UNINDENT
|
||||
.sp
|
||||
|
||||
.sp
|
||||
Randomizes the order of tests before running them. This can help detect tests
|
||||
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
|
||||
|
|
@ -2065,22 +1921,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
|
||||
|
|
@ -2112,8 +1968,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
|
||||
|
|
@ -2150,27 +2006,21 @@ in order to exchange them between processes. See
|
|||
\fI\%What can be pickled and unpickled?\fP for details.
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.sp
|
||||
Support for the value \fBauto\fP was added.
|
||||
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.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.
|
||||
.sp
|
||||
In older versions, tests that failed to load did not match tags.
|
||||
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.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
|
||||
|
|
@ -2231,7 +2081,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.)
|
||||
|
|
@ -2243,17 +2093,17 @@ 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
|
||||
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.
|
||||
database to a \fI\%fixture\fP (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
|
||||
|
|
@ -2308,8 +2158,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
|
||||
|
|
@ -2318,7 +2168,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
|
||||
|
|
@ -2352,7 +2202,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
|
||||
|
|
@ -2365,9 +2215,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.
|
||||
|
|
@ -2402,7 +2252,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
|
||||
|
|
@ -2412,7 +2262,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
|
||||
|
|
@ -2430,14 +2280,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
|
||||
|
|
@ -2450,22 +2300,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
|
||||
|
|
@ -2500,7 +2350,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
|
||||
|
|
@ -2522,7 +2372,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
|
||||
|
|
@ -2605,7 +2455,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:
|
||||
|
|
@ -2821,7 +2671,7 @@ 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 source
|
||||
script, which lives in \fI\%extras/django_bash_completion\fP in the Django source
|
||||
distribution. It enables tab\-completion of \fBdjango\-admin\fP and
|
||||
\fBmanage.py\fP commands, so you can, for instance...
|
||||
.INDENT 0.0
|
||||
|
|
@ -2834,7 +2684,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.
|
||||
.SS Black formatting
|
||||
.sp
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue