1331 lines
56 KiB
Markdown
1331 lines
56 KiB
Markdown
---
|
||
title: Django-admin和manage
|
||
date: 2020-06-08 17:18:28
|
||
tags: [Django]
|
||
categories: [Django]
|
||
author: Anges黎梦
|
||
---
|
||
|
||
> django-admin是Django的用于管理任务的命令行实用程序。
|
||
|
||
## 安装django-admin
|
||
|
||
一般安装django时自动安装django-admin，直接通过命令行即可启动。
|
||
|
||
打开命令行，输入
|
||
|
||
```
|
||
djano-admin
|
||
```
|
||
|
||
|
||
|
||
可看到命令列表，这里有一个警告，翻译：
|
||
|
||
`请注意，仅列出了Django核心命令，因为未正确配置设置（错误：请求的设置INSTALLED_APPS，但未配置设置。您必须定义环境变量DJANGO_SETTINGS_MODULE或在访问设置之前调用settings.configure（）。）
|
||
`
|
||
这是因为我们直接在django-admin中运行，并没有django项目，所以他只给我们列了自带命令。
|
||
|
||
而当我们在django项目中运行时，每一个django项目中添加的内容不同，命令也会有所添加。
|
||
|
||
若您的django-admin命令无效，则需要在python安装目录中查找django-admin.exe文件，并把所在目录添加至环境变量中。
|
||
|
||
## manage
|
||
|
||
manage.py会在每个Django项目中自动创建。
|
||
|
||
它的功能与django-admin等同，只不过它指向当前项目的settings.py文件。
|
||
|
||
## 用法
|
||
|
||
使用也非常简单，在命令行中输入命令即可。
|
||
|
||
```
|
||
django-admin \<command\> [options]
|
||
python -m django \<command\> [options]
|
||
```
|
||
|
||
以上两种用法均可使用。
|
||
|
||
command应该是可执行命令之一。 options，它是可选的，应为给定命令可用的零个或多个选项。
|
||
|
||
### help
|
||
|
||
运行以显示用法信息和每个应用程序提供的命令列表。
|
||
|
||
```
|
||
django-admin help
|
||
```
|
||
|
||
运行以显示所有可用命令的列表。
|
||
|
||
```
|
||
django-admin help --commands
|
||
```
|
||
|
||
运行以显示给定命令的描述及其可用选项的列表。
|
||
|
||
```
|
||
django-admin help \<command\>
|
||
```
|
||
|
||
### 应用名字
|
||
|
||
许多命令采用“应用程序名称”列表。
|
||
|
||
“应用程序名称”是包含模型的程序包的基本名称。
|
||
|
||
例如，如果您INSTALLED_APPS 包含字符串'mysite.blog'，则应用程序名称为blog。
|
||
|
||
### 查看版本
|
||
|
||
运行以显示当前的Django版本。
|
||
|
||
```
|
||
django-admin version
|
||
```
|
||
|
||
### 显示调试输出
|
||
|
||
使用--verbosity指定的通知和调试信息量是django-admin打印到控制台。
|
||
|
||
## 常用命令
|
||
|
||
### check
|
||
**django-admin check [app_label [app_label ...]]**
|
||
使用系统检查框架检查整个Django项目是否存在常见问题。
|
||
默认情况下，将检查所有应用。您可以通过提供应用标签列表作为参数来检查应用的子集：
|
||
```
|
||
django-admin check auth admin myapp
|
||
```
|
||
|
||
如果您未指定任何应用，则会检查所有应用。
|
||
**--tag TAGS, -t TAGS**
|
||
系统检查框架执行许多不同类型的检查，这些检查使用标记进行分类。
|
||
您可以使用这些标记将执行的检查限制为特定类别中的检查。例如，要仅执行模型和兼容性检查，请运行：
|
||
```
|
||
django-admin check --tag models --tag compatibility
|
||
```
|
||
**--list-tags**
|
||
列出所有可用标签。
|
||
**--deploy**
|
||
激活一些仅在部署设置中相关的其他检查。
|
||
您可以在本地开发环境中使用此选项，但由于您的本地开发设置模块可能没有很多生产设置，您可能希望将check命令指向不同的设置模块，可以通过设置**DJANGO_SETTINGS_MODULE**环境变量，也可以通过通过 **--settings** 选项：
|
||
```
|
||
django-admin check --deploy --settings=production_settings
|
||
```
|
||
或者，您可以直接在生产或登台部署上运行它，以验证是否正在使用正确的设置（省略--settings）。您甚至可以将其作为集成测试套件的一部分。
|
||
```
|
||
--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
|
||
```
|
||
指定将导致命令以非零状态退出的消息级别。默认是ERROR。
|
||
|
||
----
|
||
|
||
### compilemessages
|
||
```
|
||
django-admin compilemessages
|
||
```
|
||
编译.po通过创建的文件makemessages到.mo文件与内置的gettext支持使用。
|
||
见国际化和本地化。
|
||
**--locale LOCALE, -l LOCALE**
|
||
指定要处理的区域设置。如果未提供，则处理所有语言环境。
|
||
**--exclude EXCLUDE, -x EXCLUDE**
|
||
指定要从处理中排除的区域设置。如果未提供，则不排除任何语言环境。
|
||
**--use-fuzzy, -f**
|
||
包括模糊转换为编译文件。用法示例：
|
||
```
|
||
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
|
||
```
|
||
|
||
----
|
||
|
||
### createcachetable
|
||
|
||
```
|
||
django-admin createcachetable
|
||
```
|
||
|
||
使用设置文件中的信息创建用于数据库缓存后端的缓存表。
|
||
**--database DATABASE**
|
||
指定将在其中创建缓存表的数据库。默认为 default。
|
||
**--dry-run**
|
||
打印将在不实际运行的情况下运行的SQL，以便您可以自定义它或使用迁移框架。
|
||
|
||
-----
|
||
|
||
#### dbshell
|
||
```
|
||
django-admin dbshell
|
||
```
|
||
运行在您指定的数据库引擎的命令行客户端 ENGINE的设置，在您指定的连接参数USER，PASSWORD等等，设置。
|
||
|
||
* 对于PostgreSQL，它运行psql命令行客户端。
|
||
* 对于MySQL，它运行mysql命令行客户端。
|
||
* 对于SQLite，它运行sqlite3命令行客户端。
|
||
* 对于Oracle，这将运行sqlplus命令行客户端。
|
||
|
||
此命令假定程序对你的PATH，这样的程序名（一个简单的通话psql，mysql，sqlite3，sqlplus）会发现，在正确的地方节目。
|
||
无法手动指定程序的位置。
|
||
|
||
```
|
||
--database DATABASE
|
||
```
|
||
|
||
指定要在其上打开shell的数据库。默认为default。
|
||
|
||
-----
|
||
|
||
#### diffsettings
|
||
```
|
||
django-admin diffsettings
|
||
```
|
||
显示当前设置文件与Django默认设置（或指定的其他设置文件--default）之间的差异。
|
||
默认设置中未显示的设置后跟"###"。
|
||
|
||
例如，默认设置没有定义ROOT_URLCONF，因此 在输出中 ROOT_URLCONF后跟。
|
||
"###"diffsettings
|
||
|
||
**--all**
|
||
显示所有设置，即使它们具有Django的默认值。此类设置以前缀为前缀"##"。
|
||
**--default MODULE**
|
||
设置模块用于比较当前设置。留空以与Django的默认设置进行比较。
|
||
**--output {hash,unified}**
|
||
指定输出格式。可用值为hash和unified。 hash是显示上述输出的默认模式。 unified显示类似的输出。默认设置以减号为前缀，后跟带有加号前缀的更改设置。diff -u
|
||
|
||
----
|
||
|
||
### dumpdata
|
||
```
|
||
django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]
|
||
```
|
||
输出到标准输出与指定应用程序关联的数据库中的所有数据。
|
||
如果未提供应用程序名称，则将转储所有已安装的应用程序。
|
||
输出dumpdata可以用作输入loaddata。
|
||
请注意，dumpdata使用模型上的默认管理器来选择要转储的记录。
|
||
如果您使用自定义管理器作为默认管理器并且它过滤了一些可用记录，则不会转储所有对象。
|
||
**--all, -a**
|
||
使用Django的基本管理器，转储可能由自定义管理器过滤或修改的记录。
|
||
**--format FORMAT**
|
||
指定输出的序列化格式。默认为JSON。支持的格式以序列化格式列出。
|
||
**--indent INDENT**
|
||
指定要在输出中使用的缩进空格数。默认值 None显示单行上的所有数据。
|
||
**--exclude EXCLUDE, -e EXCLUDE**
|
||
防止app_label.ModelName转储特定应用程序或模型（以形式指定 ）。
|
||
如果指定模型名称，则输出将限制为该模型，而不是整个应用程序。
|
||
您还可以混合应用程序名称和型号名称。
|
||
如果要排除多个应用程序，请多次传递--exclude：
|
||
```
|
||
django-admin dumpdata --exclude=auth --exclude=contenttypes
|
||
```
|
||
**--database DATABASE**
|
||
指定将从中转储数据的数据库。
|
||
默认为default。
|
||
**--natural-foreign**
|
||
使用natural_key()模型方法序列化任何外键和与定义方法的类型的对象的多对多关系。
|
||
如果要转储contrib.auth Permission对象或contrib.contenttypes ContentType对象，则应该使用此标志。
|
||
**--natural-primary**
|
||
忽略此对象的序列化数据中的主键，因为它可以在反序列化期间计算。
|
||
**--pks PRIMARY_KEYS**
|
||
仅输出由逗号分隔的主键列表指定的对象。这仅在转储一个模型时可用。
|
||
默认情况下，输出模型的所有记录。
|
||
**--output OUTPUT, -o OUTPUT**
|
||
指定要将序列化数据写入的文件。默认情况下，数据转到标准输出。
|
||
设置此选项且--verbosity大于0（默认值）时，终端中将显示进度条。
|
||
|
||
----
|
||
|
||
### flush
|
||
```
|
||
django-admin flush
|
||
```
|
||
从数据库中删除所有数据并重新执行任何后同步处理程序。
|
||
已清除已应用迁移的表。
|
||
如果您希望从空数据库开始并重新运行所有迁移，则应删除并重新创建数据库，然后再运行migrate。
|
||
**--noinput, --no-input**
|
||
禁止所有用户提示。
|
||
**--database DATABASE**
|
||
指定要刷新的数据库。默认为default。
|
||
|
||
----
|
||
|
||
|
||
### inspectdb
|
||
```
|
||
django-admin inspectdb [table [table ...]]
|
||
```
|
||
反映NAME设置指向的数据库中的数据库表，并将 Django模型模块（**models.py** 文件）输出到标准输出。
|
||
|
||
您可以通过将其名称作为参数传递来选择要检查的表或视图。
|
||
|
||
如果未提供参数，则仅在使用该 **--include-views** 选项时才为视图创建模型。
|
||
|
||
如果使用该 **--include-partitions** 选项，则在PostgreSQL上创建分区表的模型。
|
||
|
||
如果您有一个遗留数据库，您可以使用它来使用Django。
|
||
|
||
该脚本将检查数据库并为其中的每个表创建一个模型。
|
||
|
||
正如您所料，创建的模型将具有表中每个字段的属性。
|
||
|
||
请注意，inspectdb其字段名称输出中有一些特殊情况：
|
||
|
||
* 如果inspectdb无法将列的类型映射到模型字段类型，它将使用TextField并将在生成的模型中的字段旁边插入Python注释 。
|
||
已识别的字段可能取决于中列出的应用 。
|
||
例如，添加了对几种PostgreSQL特定字段类型的识别。
|
||
'This field type is aguess.'INSTALLED_APPSdjango.contrib.postgres
|
||
|
||
* 如果数据库列名是Python保留字（例如 'pass'，'class'或'for'），inspectdb则会附加'_field' 到属性名称。
|
||
例如，如果表具有列 'for'，则生成的模型将具有一个字段'for_field'，其db_column属性设置为'for'。inspectdb将在该字段旁边插入Python注释 。
|
||
'Field renamed because it was a Python reserved word.'
|
||
|
||
此功能用作快捷方式，而不是确定的模型生成。
|
||
|
||
运行它之后，您将需要自己查看生成的模型以进行自定义。
|
||
|
||
特别是，您需要重新排列模型的顺序，以便正确排序引用其他模型的模型。
|
||
|
||
当default在模型字段上指定a 时，Django不会创建数据库默认值 。
|
||
|
||
同样，数据库默认值不会转换为模型字段默认值或以任何方式检测inspectdb。
|
||
|
||
默认情况下，inspectdb创建非托管模型。
|
||
|
||
也就是说， 在模型的类中告诉Django不要管理每个表的创建，修改和删除。
|
||
|
||
如果你想让Django管理表的生命周期，你需要将选项更改 为（或者只是删除它，因为它是默认值）。managed = FalseMetamanagedTrueTrue
|
||
|
||
#### 特定于数据库的注释
|
||
|
||
* Oracle
|
||
* 如果--include-views使用，则为物化视图创建模型。
|
||
|
||
* PostgreSQL的
|
||
* 为外表创建模型。
|
||
* 如果--include-views使用，则为物化视图创建模型 。
|
||
* 如果--include-partitions使用，则为分区表创建模型 。
|
||
|
||
在Django 2.2中更改：增加了对外国表和物化视图的支持。
|
||
**--database DATABASE**
|
||
指定要内省的数据库。默认为default。
|
||
**--include-partitions**
|
||
Django 2.2中的新功能：
|
||
如果提供此选项，还会为分区创建模型。仅实现了对PostgreSQL的支持。
|
||
**--include-views**
|
||
Django 2.1中的新功能：
|
||
如果提供此选项，还会为数据库视图创建模型。
|
||
|
||
----
|
||
|
||
### loaddata
|
||
```
|
||
django-admin loaddata fixture [fixture ...]
|
||
```
|
||
搜索并将指定fixture的内容加载到数据库中。
|
||
**--database DATABASE**
|
||
指定要将数据加载到的数据库。默认为 default。
|
||
**--ignorenonexistent, -i**
|
||
忽略自最初生成灯具后可能已删除的字段和模型。
|
||
**--app APP_LABEL**
|
||
指定单个应用程序以查找夹具而不是查看所有应用程序。
|
||
**--format FORMAT**
|
||
指定从stdin读取的装置的序列化格式（例如， json或xml）。
|
||
**--exclude EXCLUDE, -e EXCLUDE**
|
||
不包括从给定的应用程序和/或模型（以app_label或的形式app_label.ModelName）加载灯具。多次使用该选项可排除多个应用或型号。
|
||
#### 什么是“夹具”？
|
||
一个夹具是包含数据库的序列化内容的文件的集合。
|
||
每个夹具都有一个唯一的名称，构成夹具的文件可以分布在多个应用程序的多个目录中。
|
||
Django将在三个地点搜索固定装置：
|
||
* 在fixtures每个已安装的应用程序的目录中
|
||
* 在FIXTURE_DIRS设置中指定的任何目录中
|
||
* 在夹具命名的文字路径中
|
||
|
||
Django将加载它在这些位置匹配提供的灯具名称的任何和所有灯具。
|
||
如果命名夹具具有文件扩展名，则仅加载该类型的夹具。例如：
|
||
```
|
||
django-admin loaddata mydata.json
|
||
```
|
||
只会加载调用的JSON装置mydata。夹具扩展必须对应于序列化器的注册名称 （例如，json或xml）。
|
||
如果省略扩展，Django将搜索所有可用的夹具类型以获得匹配的夹具。例如：
|
||
```
|
||
django-admin loaddata mydata
|
||
```
|
||
会寻找任何夹具类型的任何夹具mydata。如果包含fixture目录mydata.json，该夹具将作为JSON fixture加载。
|
||
命名的灯具可以包含目录组件。这些目录将包含在搜索路径中。例如：
|
||
```
|
||
django-admin loaddata foo/bar/mydata.json
|
||
```
|
||
将搜索\<app_label\>/fixtures/foo/bar/mydata.json每个已安装的应用程序， \<dirname>/foo/bar/mydata.json每个目录FIXTURE_DIRS和文字路径foo/bar/mydata.json。
|
||
|
||
处理夹具文件时，数据将按原样保存到数据库中。save()不调用模型定义的方法，并且将调用任何pre_save或 post_save信号，raw=True因为实例仅包含模型本地的属性。例如，您可能希望禁用访问夹具加载期间不存在的相关字段的处理程序，否则会引发异常：
|
||
```
|
||
from django.db.models.signals import post_savefrom .models import MyModel
|
||
|
||
def my_handler(**kwargs):
|
||
# disable the handler during fixture loading
|
||
if kwargs['raw']:
|
||
return
|
||
...
|
||
post_save.connect(my_handler, sender=MyModel)
|
||
```
|
||
|
||
您还可以编写一个简单的装饰器来封装此逻辑：
|
||
```
|
||
from functools import wraps
|
||
|
||
def disable_for_loaddata(signal_handler):
|
||
""" Decorator that turns off signal handlers when loading fixture data. """
|
||
@wraps(signal_handler)
|
||
def wrapper(*args, **kwargs):
|
||
if kwargs['raw']:
|
||
return
|
||
signal_handler(*args, **kwargs)
|
||
return wrapper
|
||
|
||
@disable_for_loaddatadef my_handler(**kwargs):
|
||
...
|
||
```
|
||
|
||
请注意，无论何时对灯具进行反序列化，此逻辑都会禁用信号loaddata。
|
||
请注意，处理夹具文件的顺序是未定义的。但是，所有夹具数据都作为单个事务安装，因此一个夹具中的数据可以引用另一个夹具中的数据。如果数据库后端支持行级约束，则将在事务结束时检查这些约束。
|
||
该dumpdata命令可用于生成输入loaddata。
|
||
|
||
----
|
||
#### 压缩灯具
|
||
夹具可以被压缩zip，gz或bz2格式。例如：
|
||
```
|
||
django-admin loaddata mydata.json
|
||
```
|
||
会寻找任何的mydata.json，mydata.json.zip， mydata.json.gz，或mydata.json.bz2。
|
||
使用zip压缩存档中包含的第一个文件。
|
||
请注意，如果使用相同的名称但不同的灯具类型两场比赛被发现（例如，如果mydata.json和 mydata.xml.gz是在相同的固件目录中找到），灯具安装将被中止，并安装在调用任何数据 loaddata将被从数据库中删除。
|
||
>MySQL与MyISAM和灯具
|
||
MySQL的MyISAM存储引擎不支持事务或约束，因此如果使用MyISAM，您将无法获得夹具数据的验证，或者如果找到多个事务文件则回滚。
|
||
|
||
----
|
||
#### 特定于数据库的灯具
|
||
如果您处于多数据库设置中，则可能需要将夹具数据加载到一个数据库中，而不是加载到另一个数据库上。
|
||
在这种情况下，您可以将数据库标识符添加到灯具的名称中。
|
||
例如，如果您的DATABASES设置已定义“主”数据库，则命名夹具mydata.master.json或 mydata.master.json.gz仅在您指定要将数据加载到master数据库时才加载夹具。
|
||
|
||
----
|
||
#### 从stdin加载灯具
|
||
您可以使用短划线作为夹具名称来加载输入sys.stdin。例如：
|
||
```
|
||
django-admin loaddata --format=json -
|
||
```
|
||
读取时stdin，--format需要选项指定 输入的序列化格式（例如，json或xml）。
|
||
加载from stdin对标准输入和输出重定向很有用。例如：
|
||
```
|
||
django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
|
||
```
|
||
|
||
----
|
||
|
||
### makemessages
|
||
```
|
||
django-admin makemessages
|
||
```
|
||
遍历当前目录的整个源树，并拉出标记为要进行转换的所有字符串。
|
||
它在conf / locale（在Django树中）或locale（用于项目和应用程序）目录中创建（或更新）消息文件。
|
||
在对消息文件进行更改之后，您需要将它们编译compilemessages为与builtin gettext支持一起使用。
|
||
此命令不需要配置设置。
|
||
但是，如果未配置设置，则命令不能忽略MEDIA_ROOT和 STATIC_ROOT目录或包含LOCALE_PATHS。
|
||
**--all, -a**
|
||
更新所有可用语言的消息文件。
|
||
**--extension EXTENSIONS, -e EXTENSIONS**
|
||
指定要检查的文件扩展名列表（默认：html，txt， py或者js如果--domain是js）。用法示例：
|
||
```
|
||
django-admin makemessages --locale=de --extension xhtml
|
||
```
|
||
用逗号分隔多个扩展名或使用-e或--extension 多次：
|
||
```
|
||
django-admin makemessages --locale=de --extension=html,txt --extension xml
|
||
```
|
||
**--locale LOCALE, -l LOCALE**
|
||
指定要处理的区域设置。
|
||
**--exclude EXCLUDE, -x EXCLUDE**
|
||
指定要从处理中排除的区域设置。如果未提供，则不排除任何语言环境。
|
||
用法示例：
|
||
```
|
||
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=f
|
||
rdjango-admin makemessages -x pt_BR
|
||
django-admin makemessages -x pt_BR -x fr
|
||
```
|
||
**--domain DOMAIN, -d DOMAIN**
|
||
指定消息文件的域。支持的选项是：
|
||
* django对于所有*.py，*.html和*.txt文件（默认）
|
||
* djangojs对于*.js文件
|
||
**--symlinks, -s**
|
||
在查找新的翻译字符串时，遵循符号链接到目录。用法示例：
|
||
```
|
||
django-admin makemessages --locale=de --symlinks
|
||
```
|
||
**--ignore PATTERN, -i PATTERN**
|
||
忽略与给定glob样式模式匹配的文件或目录。多次使用可忽略更多。
|
||
这些模式是默认使用：'CVS'，'.*'，'*~'，'*.pyc'。用法示例：
|
||
```
|
||
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
|
||
```
|
||
|
||
**--no-default-ignore**
|
||
禁用默认值
|
||
**--ignore。--no-wrap**
|
||
禁用将长消息行分成语言文件中的多行。
|
||
**--no-location**
|
||
禁止在语言文件中写入' '注释行。
|
||
使用此选项会使技术熟练的翻译人员更难理解每条消息的上下文。#: filename:line
|
||
**--add-location [{full,file,never}]**
|
||
控制语言文件中的注释行。如果选项是：#: filename:line
|
||
* full （默认情况下，如果没有给出）：这些行包括文件名和行号。
|
||
* file：行号被省略。
|
||
* never：线被抑制（相同--no-location）。
|
||
需要gettext0.19或更新。
|
||
**--keep-pot**
|
||
防止删除.pot在创建.po文件之前生成的 临时文件。这对于调试可能阻止创建最终语言文件的错误很有用。
|
||
|
||
----
|
||
|
||
### makemigrations
|
||
```
|
||
django-admin makemigrations [app_label [app_label ...]]
|
||
```
|
||
根据检测到的模型更改创建新的迁移。迁移文档中详细介绍了迁移，它们与应用程序的关系等 。
|
||
提供一个或多个应用程序名称作为参数将限制为指定的应用程序创建的迁移以及所需的任何依赖项（例如，在另一端的表ForeignKey）。
|
||
要将迁移添加到没有migrations目录makemigrations的应用程序，请使用该应用程序运行 app_label。
|
||
**--noinput, --no-input**
|
||
禁止所有用户提示。如果无法自动解决被抑制的提示，则该命令将以错误代码3退出。
|
||
**--empty**
|
||
输出指定应用程序的空迁移，以进行手动编辑。
|
||
这适用于高级用户，除非您熟悉迁移格式，迁移操作以及迁移之间的依赖关系，否则不应使用此用户。
|
||
**--dry-run**
|
||
显示在不将任何迁移文件实际写入磁盘的情况下进行的迁移。
|
||
使用此选项还将显示将要写入的完整迁移文件。
|
||
**--verbosity 3--merge**
|
||
可以修复迁移冲突。
|
||
**--name NAME, -n NAME**
|
||
允许命名生成的迁移，而不是使用生成的名称。该名称必须是有效的Python 标识符。
|
||
**--no-header**
|
||
>Django 2.2中的新功能：
|
||
|
||
生成没有Django版本和时间戳标头的迁移文件。
|
||
**--check**
|
||
makemigrations当检测到没有迁移的模型更改时，使退出处于非零状态。
|
||
|
||
----
|
||
|
||
### migrate
|
||
```
|
||
django-admin migrate [app_label] [migration_name]
|
||
```
|
||
使数据库状态与当前模型和迁移集同步。
|
||
迁移文档中详细介绍了迁移，它们与应用程序的关系等 。
|
||
此命令的行为根据提供的参数而更改：
|
||
* 没有参数：所有应用程序都运行了所有迁移。
|
||
* \<app_label\>：指定的应用程序将运行其迁移，直至最近的迁移。这可能涉及由于依赖性而运行其他应用程序的迁移。
|
||
* \<app_label\> \<migrationname\>：将数据库架构置于应用命名迁移的状态，但不应用同一应用程序中的后续迁移。如果您之前已迁移过指定的迁移，则可能涉及取消应用迁移。使用该名称zero取消应用应用的所有迁移。
|
||
|
||
**--database DATABASE**
|
||
指定要迁移的数据库。默认为default。
|
||
**--fake**
|
||
将迁移标记为应用的目标迁移（遵循上述规则），但不实际运行SQL以更改数据库模式。
|
||
这适用于高级用户在手动应用更改时直接操作当前迁移状态;
|
||
请注意，使用--fake运行会导致将迁移状态表置于需要手动恢复以使迁移正确运行的状态。
|
||
**--fake-initial**
|
||
如果所有具有该CreateModel迁移中所有操作创建的模型名称的数据库表已存在，则允许Django跳过应用程序的初始迁移 。
|
||
此选项适用于首次针对预先存在使用迁移的数据库运行迁移时使用。
|
||
但是，此选项不会检查匹配的表名称之外的匹配数据库模式，因此只有在您确信现有模式与初始迁移中记录的模式匹配时才可以安全使用。
|
||
**--plan**
|
||
>Django 2.2中的新功能：
|
||
|
||
显示将对给定migrate 命令执行的迁移操作。
|
||
**--run-syncdb**
|
||
允许在不迁移的情况下为应用创建表。
|
||
虽然不推荐这样做，但对于拥有数百个模型的大型项目，迁移框架有时会太慢。
|
||
**--noinput, --no-input**
|
||
禁止所有用户提示。示例提示是询问有关删除陈旧内容类型的问题。
|
||
|
||
----
|
||
|
||
### runserver
|
||
```
|
||
django-admin runserver [addrport]
|
||
```
|
||
在本地计算机上启动轻量级开发Web服务器。
|
||
|
||
默认情况下，服务器在IP地址的端口8000上运行127.0.0.1。
|
||
|
||
您可以明确传入IP地址和端口号。
|
||
|
||
如果以具有普通权限的用户身份运行此脚本（推荐），则可能无权在低端口号上启动端口。
|
||
|
||
低端口号保留给超级用户（root）。
|
||
|
||
此服务器使用该WSGI_APPLICATION设置指定的WSGI应用程序对象 。
|
||
|
||
请勿在生产设置中使用此服务器。
|
||
|
||
它没有经过安全审核或性能测试。（这就是它将如何保留。我们的业务是制作Web框架，而不是
|
||
Web服务器，因此改进此服务器以便能够处理生产环境超出了Django的范围。）
|
||
|
||
根据需要，开发服务器会自动为每个请求重新加载Python代码。
|
||
|
||
您无需重新启动服务器即可使代码更改生效。
|
||
|
||
但是，某些操作（如添加文件）不会触发重新启动，因此在这些情况下您必须重新启动服务器。
|
||
|
||
如果您正在使用Linux或MacOS并同时安装pywatchman和 Watchman服务，则内核信号将用于自动加载服务器（而不是每秒轮询文件修改时间戳）。
|
||
|
||
这为大型项目提供了更好的性能，减少了代码更改后的响应时间，更强大的变更检测以及降低了功耗。
|
||
>包含许多文件的大型目录可能会导致性能问题
|
||
当Watchman使用包含大型非Python目录的项目时，node_modules建议忽略此目录以获得最佳性能。有关如何执行此操作的信息，请参阅watchman文档。
|
||
|
||
>watchman超时
|
||
Watchman客户端的默认超时为5秒。您可以通过设置DJANGO_WATCHMAN_TIMEOUT环境变量来更改它。
|
||
|
||
>在Django 2.2中更改：
|
||
Watchman支持取代了对pyinotify的支持。
|
||
|
||
当您启动服务器时，每次在服务器运行时更改Python代码时，系统检查框架将检查整个Django项目是否存在一些常见错误。如果发现任何错误，它们将打印到标准输出。
|
||
|
||
您可以根据需要运行任意数量的并发服务器，只要它们位于不同的端口上即可。只需执行多次。django-admin runserver
|
||
|
||
请注意，127.0.0.1无法从网络上的其他计算机访问默认IP地址。要使您的开发服务器可以在网络上的其他计算机上查看，请使用其自己的IP地址（例如192.168.2.1）或 0.0.0.0或::（启用IPv6）。
|
||
|
||
您可以提供括号括起来的IPv6地址（例如[200a::1]:8000）。这将自动启用IPv6支持。
|
||
|
||
也可以使用包含仅ASCII字符的主机名。
|
||
|
||
如果启用了staticfiles contrib app（新项目中的默认值），runserver则将使用自己的runserver命令覆盖该命令。
|
||
|
||
记录每个请求和服务器的响应将发送到 django.server记录器。
|
||
|
||
**--noreload**
|
||
禁用自动重新加载器。这意味着如果特定的Python模块已经加载到内存中，那么在服务器运行时所做的任何Python代码更改都不会生效。
|
||
**--nothreading**
|
||
禁用在开发服务器中使用线程。默认情况下，服务器是多线程的。
|
||
**--ipv6, -6**
|
||
将IPv6用于开发服务器。这会将默认IP地址更改 127.0.0.1为::1。
|
||
#### 使用不同端口和地址的示例
|
||
IP地址上的端口8000 127.0.0.1：
|
||
```
|
||
django-admin runserver
|
||
```
|
||
IP地址上的端口8000 1.2.3.4：
|
||
```
|
||
django-admin runserver 1.2.3.4:8000
|
||
```
|
||
IP地址上的端口7000 127.0.0.1：
|
||
```
|
||
django-admin runserver 7000
|
||
```
|
||
IP地址上的端口7000 1.2.3.4：
|
||
```
|
||
django-admin runserver 1.2.3.4:7000
|
||
```
|
||
IPv6地址上的端口8000 ::1：
|
||
```
|
||
django-admin runserver -6
|
||
```
|
||
IPv6地址上的端口7000 ::1：
|
||
```
|
||
django-admin runserver -6 7000
|
||
```
|
||
IPv6地址上的端口7000 2001:0db8:1234:5678::9：
|
||
```
|
||
django-admin runserver [2001:0db8:1234:5678::9]:7000
|
||
```
|
||
主机IPv4地址上的端口8000 localhost：
|
||
```
|
||
django-admin runserver localhost:8000
|
||
```
|
||
主机IPv6地址上的端口8000 localhost：
|
||
```
|
||
django-admin runserver -6 localhost:8000
|
||
```
|
||
>**使用开发服务器提供静态文件**
|
||
默认情况下，开发服务器不为您的站点提供任何静态文件（例如CSS文件，图像，MEDIA_URL等等）。如果要配置Django以提供静态媒体，请阅读 管理静态文件（比如图片，JavaScript，CSS）。
|
||
|
||
----
|
||
|
||
### sendtestemail
|
||
```
|
||
django-admin sendtestemail [email [email ...]]
|
||
```
|
||
向指定的收件人发送测试电子邮件（以确认通过Django发送的电子邮件正在发送）。例如：
|
||
```
|
||
django-admin sendtestemail foo@example.com bar@example.com
|
||
```
|
||
有几个选项，您可以将它们的任意组合使用在一起：
|
||
**--managers**
|
||
邮件中指定的电子邮件地址MANAGERS使用 mail_managers()。
|
||
**--admins**
|
||
邮件中指定的电子邮件地址ADMINS使用 mail_admins()。
|
||
|
||
----
|
||
|
||
### shell
|
||
```
|
||
django-admin shell
|
||
```
|
||
启动Python交互式解释器。
|
||
```
|
||
--interface {ipython,bpython,python}, -i {ipython,bpython,python}
|
||
```
|
||
指定要使用的shell。默认情况下，如果安装了任何一个，Django将使用IPython或bpython。如果两者都已安装，请指定您想要的那样：
|
||
IPython的：
|
||
```
|
||
django-admin shell -i ipython
|
||
```
|
||
bpython：
|
||
```
|
||
django-admin shell -i bpython
|
||
```
|
||
如果您安装了“丰富”shell，但想强制使用“普通”Python解释器，请使用python接口名称，如下所示：
|
||
```
|
||
django-admin shell -i python
|
||
```
|
||
**--nostartup**
|
||
禁用读取“普通”Python解释器的启动脚本。默认情况下，脚本指向的脚本PYTHONSTARTUP环境变量或~/.pythonrc.py脚本被读取。
|
||
**--command COMMAND, -c COMMAND**
|
||
允许您将命令作为字符串传递给Django执行它，如下所示：
|
||
```
|
||
django-admin shell --command="import django; print(django.__version__)"
|
||
```
|
||
您还可以在标准输入上传递代码以执行它。例如：
|
||
```
|
||
$ django-admin shell \<\<EOF
|
||
> import django
|
||
> print(django.__version__)
|
||
> EOF
|
||
```
|
||
在Windows上，由于select.select()该平台的实施限制，输出REPL 。
|
||
|
||
----
|
||
|
||
### showmigrations
|
||
```
|
||
django-admin showmigrations [app_label [app_label ...]]
|
||
```
|
||
显示项目中的所有迁移。您可以选择以下两种格式之一：
|
||
**--list, -l**
|
||
列出Django所知道的所有应用程序，每个应用程序可用的迁移，以及是否应用每个迁移（由[X]迁移名称旁边标记）。
|
||
还会列出没有迁移的应用，但会在其下方打印。(no migrations)
|
||
这是默认输出格式。
|
||
**--plan, -p**
|
||
显示Django将遵循的迁移计划以应用迁移。比如 --list，应用的迁移标记为[X]。对于--verbosity 2及以上的a，还将显示迁移的所有依赖关系。
|
||
|
||
app_labels参数限制输出，但是，也可以包括提供的应用程序的依赖性。
|
||
**--database DATABASE**
|
||
指定要检查的数据库。默认为default。
|
||
|
||
### sqlflush
|
||
```
|
||
django-admin sqlflush
|
||
```
|
||
打印将为该flush 命令执行的SQL语句。
|
||
**--database DATABASE**
|
||
指定要为其打印SQL的数据库。默认为default。
|
||
|
||
----
|
||
|
||
### sqlmigrate
|
||
```
|
||
django-admin sqlmigrate app_label migration_name
|
||
```
|
||
打印指定迁移的SQL。这需要一个活动的数据库连接，它将用于解析约束名称; 这意味着您必须针对您希望稍后应用它的数据库副本生成SQL。
|
||
请注意，sqlmigrate它不会使其输出着色。
|
||
**--backwards**
|
||
生成用于取消应用迁移的SQL。默认情况下，创建的SQL用于在向前方向上运行迁移。
|
||
**--database DATABASE**
|
||
指定要为其生成SQL的数据库。默认为default。
|
||
|
||
----
|
||
|
||
### sqlsequencereset
|
||
```
|
||
django-admin sqlsequencereset app_label [app_label ...]
|
||
```
|
||
打印SQL语句以重置给定应用程序名称的序列。
|
||
序列是某些数据库引擎用于跟踪自动递增字段的下一个可用数字的索引。
|
||
使用此命令生成SQL，该SQL将修复序列与其自动递增的字段数据不同步的情况。
|
||
**--database DATABASE**
|
||
指定要为其打印SQL的数据库。默认为default。
|
||
|
||
----
|
||
|
||
### squashmigrations
|
||
```
|
||
django-admin squashmigrations app_label [start_migration_name] migration_name
|
||
```
|
||
如果可能的话，将迁移压缩到最少app_label并包括migration_name更少的迁移。
|
||
由此产生的压扁迁移可以安全地与未取消的迁移一起生活。
|
||
当start_migration_name给定，Django将只包括从迁移开始，包括这个迁移。这有助于减轻压缩RunPython和django.db.migrations.operations.RunSQL迁移操作的压缩。
|
||
**--no-optimize**
|
||
生成压缩迁移时禁用优化程序。
|
||
默认情况下，Django将尝试优化迁移中的操作以减小生成的文件的大小。
|
||
如果此过程失败或创建不正确的迁移，请使用此选项，但请同时提交有关行为的Django错误报告，因为优化是安全的。
|
||
**--noinput, --no-input**
|
||
禁止所有用户提示。
|
||
**--squashed-name SQUASHED_NAME**
|
||
设置压缩迁移的名称。省略时，名称基于第一次和最后一次迁移，_squashed_介于两者之间。
|
||
**--no-header**
|
||
>Django 2.2中的新功能：
|
||
|
||
生成没有Django版本和时间戳标头的压缩迁移文件。
|
||
|
||
----
|
||
|
||
### startapp
|
||
```
|
||
django-admin startapp name [directory]
|
||
```
|
||
为当前目录或给定目标中的给定应用程序名称创建Django应用程序目录结构。
|
||
默认情况下，新目录包含 models.py文件和其他应用程序模板文件。
|
||
如果仅给出应用程序名称，则将在当前工作目录中创建应用程序目录。
|
||
如果提供了可选目标，Django将使用该现有目录而不是创建新目录。
|
||
您可以使用 '。' 表示当前的工作目录。例如：
|
||
```
|
||
django-admin startapp myapp /Users/jezdez/Code/myapp
|
||
```
|
||
**--template TEMPLATE**
|
||
提供了路径与自定义应用程序模板文件或路径，以一个压缩文件（目录.tar.gz，.tar.bz2，.tgz，.tbz，.zip）包含应用程序模板文件。
|
||
例如，这将在创建myapp应用程序时在给定目录中查找应用程序模板：
|
||
```
|
||
django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
|
||
```
|
||
Django的也将接受的URL（ ，http，https），ftp以与应用程序模板文件压缩档案，下载和上飞提取它们。
|
||
例如，利用GitHub的功能将存储库公开为zip文件，您可以使用以下URL：
|
||
```
|
||
django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
|
||
```
|
||
**--extension EXTENSIONS, -e EXTENSIONS**
|
||
指定应使用模板引擎呈现应用程序模板中的哪些文件扩展名。默认为py。
|
||
**--name FILES, -n FILES**
|
||
指定--extension应使用模板引擎呈现应用程序模板中的哪些文件（以及匹配的文件 ）。默认为空列表。
|
||
将用于所有匹配的文件是：template context
|
||
* 传递给startapp命令的任何选项（在命令支持的选项中）
|
||
* app_name - 传递给命令的应用程序名称
|
||
* app_directory - 新创建的应用程序的完整路径
|
||
* camel_case_app_name - 驼峰案例格式的应用程序名称
|
||
* docs_version- 文档的版本：'dev'或'1.x'
|
||
* django_version - Django的版本，例如``2.0.3``
|
||
|
||
>警告
|
||
当使用Django模板引擎（默认情况下所有*.py文件）呈现应用程序模板文件时，Django还将替换包含的所有杂散模板变量。例如，如果其中一个Python文件包含解释与模板呈现相关的特定功能的文档字符串，则可能会导致错误的示例。
|
||
若要解决此问题，您可以使用templatetag 模板标记“转义”模板语法的各个部分。
|
||
此外，为了允许包含Django模板语言语法的Python模板文件同时还防止打包系统尝试字节编译无效*.py文件，.py-tpl 将以重命名的模板文件重命名为.py。
|
||
|
||
----
|
||
|
||
### startproject
|
||
```
|
||
django-admin startproject name [directory]
|
||
```
|
||
为当前目录或给定目标中的给定项目名创建Django项目目录结构。
|
||
默认情况下，新目录包含 manage.py一个项目包（包含一个settings.py和其他文件）。
|
||
如果仅给出项目名称，则将命名项目目录和项目包，\<projectname>并在当前工作目录中创建项目目录。
|
||
如果提供了可选目标，Django将使用该现有目录作为项目目录，并在其中创建manage.py项目包。
|
||
使用 '。' 表示当前的工作目录。例如：
|
||
```
|
||
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
|
||
```
|
||
**--template TEMPLATE**
|
||
指定自定义项目模板的目录，文件路径或URL。startapp --template
|
||
**--extension EXTENSIONS, -e EXTENSIONS**
|
||
指定应使用模板引擎呈现项目模板中的哪些文件扩展名。默认为py。
|
||
**--name FILES, -n FILES**
|
||
指定--extension应使用模板引擎呈现项目模板中的哪些文件（以及匹配的文件 ）。默认为空列表。
|
||
该采用的是：template context
|
||
- 传递给startproject命令的任何选项（在命令支持的选项中）
|
||
- project_name - 传递给命令的项目名称
|
||
- project_directory - 新创建项目的完整路径
|
||
- secret_key- SECRET_KEY设置的随机密钥
|
||
- docs_version- 文档的版本：'dev'或'1.x'
|
||
- django_version - Django的版本，例如``2.0.3``
|
||
|
||
----
|
||
### test
|
||
```
|
||
django-admin test [test_label [test_label ...]]
|
||
```
|
||
运行所有已安装应用的测试。
|
||
**--failfast**
|
||
在测试失败后立即停止运行测试并报告失败。
|
||
**--testrunner TESTRUNNER**
|
||
控制用于执行测试的测试运行器类。此值将覆盖设置提供的值TEST_RUNNER。
|
||
**--noinput, --no-input**
|
||
禁止所有用户提示。典型的提示是关于删除现有测试数据库的警告。
|
||
#### 测试跑步者选项
|
||
该test命令代表指定的接收选项 --testrunner。这些是默认测试运行器的选项： DiscoverRunner。
|
||
**--keepdb, -k**
|
||
在测试运行之间保留测试数据库。
|
||
这样做的优点是可以跳过create和destroy操作，这可以大大减少运行测试的时间，特别是在大型测试套件中。
|
||
如果测试数据库不存在，它将在第一次运行时创建，然后为每次后续运行保留。
|
||
在运行测试套件之前，任何未应用的迁移也将应用于测试数据库。
|
||
**--reverse, -r**
|
||
按相反的执行顺序对测试用例进行排序。这可能有助于调试未正确隔离的测试的副作用。
|
||
使用此选项时，将保留按测试类分组。
|
||
**--debug-mode**
|
||
将DEBUG设置设置True为运行测试之前。这可能有助于解决测试失败问题。
|
||
**--debug-sql, -d**
|
||
为失败的测试启用SQL日志记录。如果 --verbosity是2，则还输出传递测试中的查询。
|
||
**--parallel [N]**
|
||
在单独的并行进程中运行测试。
|
||
由于现代处理器具有多个内核，因此可以更快地运行测试。
|
||
|
||
默认情况下，--parallel每个核心运行一个进程 multiprocessing.cpu_count()。
|
||
|
||
您可以通过将其作为选项的值（例如--parallel=4，或通过设置DJANGO_TEST_PROCESSES环境变量）来调整进程数。
|
||
|
||
Django将测试用例 - unittest.TestCase子类 - 分发给子进程。
|
||
|
||
如果测试用例少于配置的进程，Django将相应地减少进程数。
|
||
|
||
每个进程都有自己的数据库。您必须确保不同的测试用例不访问相同的资源。
|
||
|
||
例如，触摸文件系统的测试用例应该创建一个供自己使用的临时目录。
|
||
|
||
此选项要求第三方tblib程序包正确显示回溯：
|
||
```
|
||
$ pip install tblib
|
||
```
|
||
Windows上不提供此功能。它也不适用于Oracle数据库后端。
|
||
|
||
如果要pdb在调试测试时使用，则必须禁用并行执行（--parallel=1）。bdb.BdbQuit如果不这样，你会看到类似的东西。
|
||
>警告
|
||
当启用测试并行化并且测试失败时，Django可能无法显示异常回溯。这可能使调试变得困难。如果遇到此问题，请在不进行并行化的情况下运行受影响的测试，以查看故障的回溯。
|
||
这是一个已知的限制。它源于需要序列化对象以便在进程之间交换它们。
|
||
|
||
**--tag TAGS**
|
||
仅运行标有指定标签的测试。可以多次指定并结合使用。test
|
||
**--exclude-tag--exclude-tag EXCLUDE_TAGS**
|
||
排除标有指定标签的测试。可以多次指定并结合使用。test --tag
|
||
|
||
----
|
||
### testserver
|
||
```
|
||
django-admin testserver [fixture [fixture ...]]
|
||
```
|
||
runserver使用来自给定fixture的数据运行Django开发服务器（如）。
|
||
例如，这个命令：
|
||
```
|
||
django-admin testserver mydata.json
|
||
```
|
||
...将执行以下步骤：
|
||
1.创建一个测试数据库，如在测试数据库。
|
||
2.使用来自给定灯具的灯具数据填充测试数据库。
|
||
3.运行Django开发服务器（如runserver），指向这个新创建的测试数据库而不是生产数据库。
|
||
|
||
这在很多方面都很有用：
|
||
* 在编写视图如何使用某些夹具数据进行单元测试时，您可以testserver手动使用Web浏览器中的视图进行交互。
|
||
* 假设您正在开发Django应用程序并拥有一个您希望与之交互的数据库的“原始”副本。您可以将数据库转储到fixture（使用dumpdata上面解释的命令），然后使用testserver该数据运行Web应用程序。通过这种安排，您可以灵活地以任何方式搞乱数据，因为您知道您所做的任何数据更改都只是针对测试数据库。
|
||
|
||
请注意，此服务器也不会自动检测对你的Python代码（如runserver不）。但是，它会检测模板的更改。
|
||
**--addrport ADDRPORT**
|
||
指定默认值为的其他端口或IP地址和端口 127.0.0.1:8000。此值遵循完全相同的格式，并且与runserver命令的参数具有完全相同的功能。
|
||
|
||
例子：
|
||
使用fixture1和在端口7000上运行测试服务器fixture2：
|
||
```
|
||
django-admin testserver --addrport 7000 fixture1 fixture2
|
||
django-admin testserver fixture1 fixture2 --addrport 7000
|
||
```
|
||
（上面的陈述是等价的。我们将它们都包含在内，以证明选项是在夹具参数之前还是之后无关紧要。）
|
||
|
||
使用test夹具在1.2.3.4:7000上运行：
|
||
```
|
||
django-admin testserver --addrport 1.2.3.4:7000 test
|
||
```
|
||
**--noinput, --no-input**
|
||
禁止所有用户提示。典型的提示是关于删除现有测试数据库的警告。
|
||
|
||
----
|
||
|
||
## 应用程序提供的命令
|
||
某些命令仅在实现它们 的django.contrib应用程序 可用时才可用。本节按其应用程序对它们进行分组。enabled
|
||
### django.contrib.auth
|
||
#### changepassword
|
||
```
|
||
django-admin changepassword [\<username\>]
|
||
```
|
||
此命令仅在安装了Django的身份验证系统（django.contrib.auth）时可用。
|
||
|
||
允许更改用户密码。它会提示您为给定用户输入两次新密码。如果条目相同，则立即成为新密码。如果您未提供用户，该命令将尝试更改其用户名与当前用户匹配的密码。
|
||
|
||
**--database DATABASE**
|
||
指定要查询用户的数据库。默认为default。
|
||
用法示例：
|
||
```
|
||
django-admin changepassword ringo
|
||
```
|
||
|
||
----
|
||
#### createsuperuser
|
||
```
|
||
django-admin createsuperuser
|
||
```
|
||
此命令仅在安装了Django的身份验证系统（django.contrib.auth）时可用。
|
||
创建超级用户帐户（具有所有权限的用户）。如果您需要创建初始超级用户帐户，或者需要以编程方式为站点生成超级用户帐户，这将非常有用。
|
||
以交互方式运行时，此命令将提示输入新超级用户帐户的密码。以非交互方式运行时，不会设置密码，并且在为其手动设置密码之前，超级用户帐户将无法登录。
|
||
**--username USERNAME**
|
||
**--email EMAIL**
|
||
可以使用命令行上的--username和--email参数提供新帐户的用户名和电子邮件地址。如果未提供其中任何一个，createsuperuser则在交互式运行时将提示它。
|
||
**--database DATABASE**
|
||
指定将保存超级用户对象的数据库。
|
||
get_input_data()如果要自定义数据输入和验证，则可以对管理命令进行子类化并覆盖。
|
||
例如，如果您有一个ForeignKeyin REQUIRED_FIELDS并希望允许创建实例而不是输入现有实例的主键，那么它可能很有用。
|
||
|
||
----
|
||
|
||
### django.contrib.contenttypes
|
||
#### remove_stale_contenttypes
|
||
```
|
||
django-admin remove_stale_contenttypes
|
||
```
|
||
此命令仅在安装了Django的contenttypes app（django.contrib.contenttypes）时可用。
|
||
删除数据库中的陈旧内容类型（来自已删除的模型）。依赖于已删除内容类型的任何对象也将被删除。在确认可以继续删除之前，将显示已删除对象的列表。
|
||
**--database DATABASE**
|
||
指定要使用的数据库。默认为default。
|
||
|
||
----
|
||
|
||
### django.contrib.gis
|
||
#### ogrinspect
|
||
此命令仅在安装GeoDjango （django.contrib.gis）时可用。
|
||
请参阅descriptionGeoDjango文档中的内容。
|
||
|
||
----
|
||
|
||
### django.contrib.sessions
|
||
#### clearsessions
|
||
```
|
||
django-admin clearsessions
|
||
```
|
||
可以作为cron作业运行，也可以直接清除过期的会话。
|
||
|
||
----
|
||
|
||
### django.contrib.sitemaps
|
||
#### ping_google
|
||
此命令仅在安装Sitemaps framework（django.contrib.sitemaps）时可用。
|
||
```
|
||
django-admin ping_google [sitemap_url]
|
||
```
|
||
将站点地图应用程序添加到项目后，您还可以使用ping_google管理命令ping Google ：
|
||
```
|
||
python manage.py ping_google [/sitemap.xml]
|
||
```
|
||
**--sitemap-uses-http**
|
||
>Django 2.2中的新功能：
|
||
|
||
如果您的站点地图使用http而不是，请使用此选项https。
|
||
|
||
----
|
||
|
||
### django.contrib.staticfiles
|
||
#### collectstatic
|
||
仅当安装了静态文件application（django.contrib.staticfiles）时，此命令才可用。
|
||
```
|
||
django-admin collectstatic
|
||
```
|
||
将静态文件收集到STATIC_ROOT。
|
||
|
||
默认情况下，重复文件名的解析方式与模板解析的工作方式类似：将首先使用在其中一个指定位置找到的文件。如果您感到困惑，该findstatic命令可以帮助您显示找到的文件。
|
||
|
||
在后续collectstatic运行（如果STATIC_ROOT不为空）时，仅当文件的修改时间戳大于文件的时间戳时才复制文件STATIC_ROOT。因此，如果从中删除应用程序 INSTALLED_APPS，最好使用该选项以删除过时的静态文件。collectstatic --clear
|
||
|
||
使用。搜索文件。默认值是中定义的所有地点寻找 ，并在由指定的应用程序的目录设置。enabled findersSTATICFILES_DIRS'static'INSTALLED_APPS
|
||
|
||
的collectstatic管理命令调用 post_process() 的方法STATICFILES_STORAGE每次运行后，并传递的已发现由管理命令的路径列表。它还接收所有命令行选项collectstatic。ManifestStaticFilesStorage 默认情况下使用此选项。
|
||
|
||
默认情况下，收集的文件从中接收权限，FILE_UPLOAD_PERMISSIONS并从中 收集目录FILE_UPLOAD_DIRECTORY_PERMISSIONS。如果您希望对这些文件和/或目录具有不同的权限，则可以将其中一个静态文件存储类子 类化，并分别指定 file_permissions_mode和/或directory_permissions_mode参数。例如：
|
||
```
|
||
from django.contrib.staticfiles import storage
|
||
|
||
class MyStaticFilesStorage(storage.StaticFilesStorage):
|
||
def __init__(self, *args, **kwargs):
|
||
kwargs['file_permissions_mode'] = 0o640
|
||
kwargs['directory_permissions_mode'] = 0o760
|
||
super().__init__(*args, **kwargs)
|
||
```
|
||
然后将STATICFILES_STORAGE设置设置为 'path.to.MyStaticFilesStorage'。
|
||
|
||
一些常用的选项是：
|
||
|
||
**--noinput, --no-input**
|
||
不要提示用户输入任何类型。
|
||
|
||
**--ignore PATTERN, -i PATTERN**
|
||
忽略与此glob样式模式匹配的文件，目录或路径。多次使用可忽略更多。指定路径时，始终使用正斜杠，即使在Windows上也是如此。
|
||
|
||
>在Django 2.2中更改：
|
||
>路径匹配已添加。
|
||
|
||
**--dry-run, -n**
|
||
做一切，除了修改文件系统。
|
||
|
||
**--clear, -c**
|
||
在尝试复制或链接原始文件之前清除现有文件。
|
||
|
||
**--link, -l**
|
||
创建指向每个文件的符号链接，而不是复制。
|
||
|
||
**--no-post-process**
|
||
不要调用已post_process() 配置的STATICFILES_STORAGE存储后端的 方法。
|
||
|
||
**--no-default-ignore**
|
||
不要忽略常见的私有glob样式模式'CVS'，'.*' 以及'*~'。
|
||
|
||
有关选项的完整列表，请通过运行来参考命令自己的帮助：
|
||
|
||
```
|
||
$ python manage.py collectstatic --help
|
||
```
|
||
#### 自定义被忽略的模式列表
|
||
默认忽略模式列表可以以比在每次调用时提供命令选项 更持久的方式进行自定义。提供自定义 类，覆盖此类的属性并替换 为您设置中的该类路径 ：['CVS', '.*', '*~']--ignorecollectstaticAppConfigignore_patterns'django.contrib.staticfiles'INSTALLED_APPS
|
||
```
|
||
from django.contrib.staticfiles.apps import StaticFilesConfig
|
||
|
||
class MyStaticFilesConfig(StaticFilesConfig):
|
||
ignore_patterns = [...] # your custom ignore list
|
||
```
|
||
|
||
----
|
||
#### findstatic
|
||
仅当安装了静态文件application（django.contrib.staticfiles）时，此命令才可用。
|
||
```
|
||
django-admin findstatic staticfile [staticfile ...]
|
||
```
|
||
使用启用的查找程序搜索一个或多个相对路径。
|
||
|
||
例如：
|
||
```
|
||
$ python manage.py findstatic css/base.css admin/js/core.js
|
||
Found 'css/base.css' here:
|
||
/home/special.polls.com/core/static/css/base.css
|
||
/home/polls.com/core/static/css/base.css
|
||
Found 'admin/js/core.js' here:
|
||
/home/polls.com/src/django/contrib/admin/media/js/core.js
|
||
```
|
||
**findstatic --first**
|
||
默认情况下，找到所有匹配的位置。要仅返回每个相对路径的第一个匹配项，请使用以下--first选项：
|
||
```
|
||
$ python manage.py findstatic css/base.css --first
|
||
Found 'css/base.css' here:
|
||
/home/special.polls.com/core/static/css/base.css
|
||
```
|
||
这是一个调试辅助工具; 它会向您显示将为给定路径收集哪个静态文件。
|
||
|
||
通过将--verbosity标志设置为0，您可以抑制额外输出并获取路径名称：
|
||
|
||
```
|
||
$ python manage.py findstatic css/base.css --verbosity 0
|
||
/home/special.polls.com/core/static/css/base.css
|
||
/home/polls.com/core/static/css/base.css
|
||
```
|
||
另一方面，通过将--verbosity标志设置为2，您可以获取所有搜索到的目录：
|
||
|
||
```
|
||
$ python manage.py findstatic css/base.css --verbosity 2
|
||
Found 'css/base.css' here:
|
||
/home/special.polls.com/core/static/css/base.css
|
||
/home/polls.com/core/static/css/base.css
|
||
Looking in the following locations:
|
||
/home/special.polls.com/core/static
|
||
/home/polls.com/core/static
|
||
/some/other/path/static
|
||
```
|
||
|
||
----
|
||
|
||
### 默认选项
|
||
虽然某些命令可能允许自己的自定义选项，但每个命令都允许以下选项：
|
||
**--pythonpath PYTHONPATH**
|
||
将给定的文件系统路径添加到Python 导入搜索路径。如果未提供，django-admin则使用PYTHONPATH环境变量。此选项是不必要的manage.py，因为它负责为您设置Python路径。
|
||
用法示例：
|
||
```
|
||
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
|
||
```
|
||
**--settings SETTINGS**
|
||
指定要使用的设置模块。设置模块应该是Python包语法，例如mysite.settings。如果未提供， django-admin则使用DJANGO_SETTINGS_MODULE环境变量。
|
||
|
||
此选项是不必要的manage.py，因为它settings.py默认使用当前项目。
|
||
用法示例：
|
||
```
|
||
django-admin migrate --settings=mysite.settings
|
||
```
|
||
**--traceback**
|
||
CommandError 引发a时显示完整的堆栈跟踪。默认情况下，django-admin将在CommandError发生时显示简单的错误消息，并在任何其他异常时显示 完整的堆栈跟踪。
|
||
用法示例：
|
||
```
|
||
django-admin migrate --traceback
|
||
```
|
||
**--verbosity {0,1,2,3}, -v {0,1,2,3}**
|
||
指定命令应打印到控制台的通知和调试信息量。
|
||
* 0 意味着没有输出。
|
||
* 1 表示正常输出（默认）。
|
||
* 2 表示详细输出。
|
||
* 3意味着非常详细的输出。
|
||
|
||
用法示例：
|
||
```
|
||
django-admin migrate --verbosity 2
|
||
```
|
||
**--no-color**
|
||
禁用彩色命令输出。某些命令将其输出格式化为彩色。例如，错误将以红色打印到控制台，SQL语句将突出显示语法。
|
||
用法示例：
|
||
```
|
||
django-admin runserver --no-color
|
||
```
|
||
**--force-color**
|
||
>Django 2.2中的新功能：
|
||
|
||
如果它将被禁用，则强制命令输出的颜色化，如语法着色中所述。例如，您可能希望将彩色输出管道传输到另一个命令。
|
||
|
||
----
|
||
|
||
### 额外的细节
|
||
#### 语法着色
|
||
如果终端支持ANSI色输出，django-admin/ manage.pycommands将使用漂亮的颜色编码输出。如果您将命令的输出传递给另一个程序，除非使用该--force-color选项，否则它不会使用颜色代码。
|
||
|
||
在Windows下，本机控制台不支持ANSI转义序列，因此默认情况下没有颜色输出。但是你可以安装ANSICON 第三方工具，Django命令会检测它的存在，并将像在基于Unix的平台上一样利用其服务来进行颜色输出。
|
||
|
||
用于语法突出显示的颜色可以自定义。Django配有三种调色板：
|
||
- dark，适合在黑色背景上显示白色文本的终端。这是默认调色板。
|
||
- light，适合在白色背景上显示黑色文本的终端。
|
||
- nocolor，禁用语法高亮显示。
|
||
|
||
您可以通过设置DJANGO_COLORS环境变量来指定要使用的调色板来选择调色板。例如，要light在Unix或OS / X BASH shell下指定调色板，可以在命令提示符下运行以下命令：
|
||
```
|
||
export DJANGO_COLORS="light"
|
||
```
|
||
您还可以自定义使用的颜色。Django指定了许多使用颜色的角色：
|
||
- error - 一个重大错误。
|
||
- notice - 一个小错误。
|
||
- success - 成功。
|
||
- warning - 一个警告。
|
||
- sql_field - SQL中模型字段的名称。
|
||
- sql_coltype - SQL中模型字段的类型。
|
||
- sql_keyword - SQL关键字。
|
||
- sql_table - SQL中模型的名称。
|
||
- http_info - 1XX HTTP信息服务器响应。
|
||
- http_success - 2XX HTTP Success服务器响应。
|
||
- http_not_modified - 304 HTTP未修改的服务器响应。
|
||
- http_redirect - 304以外的3XX HTTP重定向服务器响应。
|
||
- http_not_found - 404 HTTP未找到服务器响应。
|
||
- http_bad_request - 除404之外的4XX HTTP错误请求服务器响应。
|
||
- http_server_error - 5XX HTTP服务器错误响应。
|
||
- migrate_heading - 迁移管理命令中的标题。
|
||
- migrate_label - 迁移名称。
|
||
|
||
可以从以下列表中为每个角色分配特定的前景色和背景色：
|
||
- black
|
||
- red
|
||
- green
|
||
- yellow
|
||
- blue
|
||
- magenta
|
||
- cyan
|
||
- white
|
||
|
||
然后可以使用以下显示选项修改这些颜色中的每一种：
|
||
- bold
|
||
- underscore
|
||
- blink
|
||
- reverse
|
||
- conceal
|
||
|
||
颜色规范遵循以下模式之一：
|
||
- role=fg
|
||
- role=fg/bg
|
||
- role=fg,option,option
|
||
- role=fg/bg,option,option
|
||
|
||
其中role是有效颜色角色的名称，fg是前景颜色，bg是背景颜色，每个颜色option 都是颜色修改选项之一。然后用分号分隔多种颜色规格。例如：
|
||
```
|
||
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
|
||
```
|
||
将指定使用蓝色闪烁黄色显示错误，并使用洋红色显示通知。所有其他颜色角色将保持未着色。
|
||
也可以通过扩展基础调色板来指定颜色。如果将调色板名称放在颜色规范中，则将加载该调色板隐含的所有颜色。所以：
|
||
```
|
||
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
|
||
```
|
||
将指定使用浅色调色板中的所有颜色， 但错误和通知的颜色除外，这些颜色将按指定覆盖。
|
||
|
||
----
|
||
|
||
### Bash完成
|
||
如果您使用Bash shell，请考虑安装Django bash完成脚本，该脚本extras/django_bash_completion位于Django源代码发行版中。它启用tab-completion django-admin和 manage.py命令，所以你可以，例如......
|
||
- 类型django-admin。
|
||
- 按[TAB]查看所有可用选项。
|
||
- 键入sql，然后按[TAB]，查看名称以其开头的所有可用选项sql。
|
||
|
||
----
|
||
|
||
### 从代码运行管理命令
|
||
```
|
||
django.core.management.call_command（name，* args，** options）
|
||
```
|
||
从代码使用中调用管理命令call_command。
|
||
`name`
|
||
要调用的命令的名称或命令对象。除非测试需要该对象，否则优先传递名称。
|
||
`*args`
|
||
命令接受的参数列表。参数传递给参数解析器，因此您可以使用与命令行相同的样式。例如，。call_command('flush', '--verbosity=0')
|
||
`**options`
|
||
命令行上接受的命名选项。选项传递给命令而不触发参数解析器，这意味着您需要传递正确的类型。例如，（零必须是整数而不是字符串）。call_command('flush', verbosity=0)
|
||
例子：
|
||
```
|
||
from django.core import management
|
||
from django.core.management.commands import loaddata
|
||
|
||
management.call_command('flush', verbosity=0, interactive=False)
|
||
management.call_command('loaddata', 'test_data', verbosity=0)
|
||
management.call_command(loaddata.Command(), 'test_data', verbosity=0)
|
||
```
|
||
请注意，不带参数的命令选项将作为带有True或的关键字传递False，如interactive上面的选项所示。
|
||
可以使用以下语法之一传递命名参数：
|
||
```
|
||
# Similar to the command line
|
||
management.call_command('dumpdata', '--natural-foreign')
|
||
|
||
# Named argument similar to the command line minus the initial dashes and
|
||
# with internal dashes replaced by underscores
|
||
management.call_command('dumpdata', natural_foreign=True)
|
||
|
||
# `use_natural_foreign_keys` is the option destination variable
|
||
management.call_command('dumpdata', use_natural_foreign_keys=True)
|
||
```
|
||
|
||
使用call_command()而不是django-admin或时，某些命令选项具有不同的名称manage.py。例如，转换为。要查找要用于的关键字参数名称 ，请检查传递给的参数的命令源代码。
|
||
django-admin createsuperuser --no-inputcall_command('createsuperuser', interactive=False)call_command()destparser.add_argument()
|
||
采用多个选项的命令选项将传递给列表：
|
||
```
|
||
management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
|
||
```
|
||
所述的返回值call_command()的功能是一样的的返回值handle()的命令的方法。
|
||
|
||
----
|
||
|
||
### 输出重定向
|
||
请注意，您可以重定向标准输出和错误流，因为所有命令都支持stdout和stderr选项。
|
||
例如，你可以写：
|
||
```
|
||
with open('/path/to/command_output', 'w') as f:
|
||
management.call_command('dumpdata', stdout=f)
|
||
```
|
||
|
||
|