django-admin
和manage.py
¶django-admin
是用于管理Django的命令行工具集。
本文档将概述它的全部功能。
此外, manage.py
会在每个Django项目中自动生成。
manage.py
与django-admin
相同,但为您处理以下几件事情:
sys.path
。DJANGO_SETTINGS_MODULE
环境变量,因此它指向工程的 settings.py
文件。如果你是通过自带的 django-admin
工具来安装Django 的,setup.py
脚本应该在你的系统路径里面。 如果不在你的系统路径里面, 你应该能在你 Python 安装目录下的 site-packages/django/bin
里找到, 可以创建一个软链接到你的系统路径里面, 比如 /usr/local/bin
。
对于没有符号链接功能的Windows用户,您可以将django-admin.exe
复制到现有路径上的某个位置,或编辑PATH
设置 设置 - 控制 面板 - 系统 - 高级 -
环境...
)指向其安装位置。
如果你在编写某个项目的时候, 通常使用manage.py
要比 django-admin
容易一些。 如果你需要在不同的 Django 设置文件中来回切换,可以使用django-admin
加上 DJANGO_SETTINGS_MODULE
或是 --settings
参数。
本文档中的命令行示例使用django-admin
一致,但任何示例都可以使用manage.py
或python -m django
同样如此。
$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]
command
应是本节文档中所列出的其中一项。
options
, 可选项,应该是可选值中的0项或多项。
django-admin help
¶运行 django-admin help
显示使用信息和每个应用的命令列表。
运行 django-admin help --commands
显示一个包含所有可用命令的列表
运行 django-admin help <command>
来显示某一个命令的描述及其可用的命令列表。
许多命令会列出“应用程序名称”。“应用程序名称”是包含模型的软件包的基本名称。 例如,如果你的 INSTALLED_APPS
中包含 'mysite.blog'
,那么app name就是 blog
.
django-admin version
¶键入 django-admin version
来获取你当前所使用的Django版本。
输出遵循 PEP 440中描述的模式:
1.4.dev17026
1.4a1
1.4
使用--verbosity
指定django-admin
打印到控制台的通知和调试信息量。
check
¶django-admin check [app_label [app_label ...]]
¶使用system check framework来检查整个Django项目是否存在常见问题。
默认情况下,所有应用都将被选中。 您可以通过提供应用标签列表作为参数来检查应用的子集:
django-admin check auth admin myapp
如果你没有指定任何一个应用,那么将对全部的应用进行检查。
- 标签
TAGS
,
-t
TAGS
¶The system check framework performs many different types of checks that are categorized with tags. 您可以使用这些标记将执行的检查仅限于特定类别中的检查。 例如,要仅执行模型和兼容性检查,请运行:
django-admin check --tag models --tag compatibility
列出所有可用的标签。
- 部署 T0> T1> ¶ T2>
激活仅在部署设置中相关的一些其他检查。
您可以在本地开发环境中使用此选项,但由于本地开发设置模块可能没有很多生产设置,因此您可能希望将check
命令指向不同的设置模块,通过设置DJANGO_SETTINGS_MODULE
环境变量,或传递--settings
选项:
django-admin check --deploy --settings=production_settings
或者,您可以直接在生产或分段部署中运行它,以验证正确的设置是否正在使用(省略--settings
)。 您甚至可以将它作为集成测试套件的一部分。
--fail级
{CRITICAL,ERROR,WARNING,INFO,DEBUG}
¶指定使命令退出非零状态的消息级别。 默认值为ERROR
。
compilemessages
¶django-admin compilemessages
¶将由makemessages
创建的.po
文件编译为.mo
文件,以便与内置的gettext支持一起使用。 请参阅Internationalization and localization。
--locale
LOCALE
,
-l
LOCALE
¶指定要处理的区域设置。 如果未提供,则处理所有语言环境。
- 排除
排除
,
-X
排除
¶指定要从处理中排除的区域设置。 如果未提供,则不排除语言环境。
- 使用模糊 T0>
,
-f T0> T1> ¶ T2>
将模糊翻译包含到编译文件中。
用法示例:
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
¶使用设置文件中的信息创建用于数据库缓存后端的缓存表。 有关详细信息,请参阅Django’s cache framework。
- 数据库
数据库
¶指定将在其中创建高速缓存表的数据库。 默认为default
。
- 空转 T0> T1> ¶ T2>
打印要运行的SQL,而不实际运行它,因此您可以自定义它或使用迁移框架。
dbshell
¶django-admin dbshell
¶运行您的ENGINE
设置中指定的数据库引擎的命令行客户机,其中USER
,PASSWORD
等中指定了连接参数。 ,设置。
psql
命令行客户端。mysql
命令行客户端。sqlite3
命令行客户端。sqlplus
命令行客户端。This command assumes the programs are on your PATH
so that a simple call to
the program name (psql
, mysql
, sqlite3
, sqlplus
) will find the
program in the right place. 没有办法手动指定程序的位置。
- 数据库
数据库
¶指定打开shell的数据库。 默认为default
。
diffsettings
¶django-admin diffsettings
¶显示当前设置文件与Django的默认设置(或由--default
指定的其他设置文件)之间的差异。
在默认设置中没有出现的设置后面跟着 "###"
. 例如,默认设置中没有定义 ROOT_URLCONF
, 所以在输出 diffsettings
时 ROOT_URLCONF
后面跟着 "###"
- 均 T0> T1> ¶ T2>
显示所有设置,即使它们具有Django的默认值。 此类设置的前缀为"###"
。
- 默认
MODULE
¶设置模块比较当前设置。 留空以比较Django的默认设置。
dumpdata
¶django-admin dumpdata [app_label [.ModelName] [app_label [.ModelName] ...]]
¶该命令将所有与被命名应用相关联的数据库中的数据输出到标准输出。
如果在dumpdate命令后面未指定Django应用名,则Django项目中安装的所有应用的数据都将被dump到fixture中。
dumpdata
命令的输出可作为loaddata
命令的输入
请注意,dumpdata
使用模型上的默认管理器来选择要转储的记录。 如果您使用custom manager作为默认管理器,并过滤一些可用记录,则不会转储所有对象。
- 均 T0>
,
-a T0> T1> ¶ T2>
使用Django的基础经理,倾销记录,否则可能会被自定义管理员过滤或修改。
- 格式
格式
¶指定输出的序列化格式。 默认为JSON。 支持的格式列在Serialization formats中。
--indent
INDENT
¶指定要在输出中使用的缩进空格的数量。 默认为None
,它显示单行上的所有数据。
- 排除
排除
,
-e
排除
¶防止转储特定的应用程序或模型(以app_label.ModelName
的形式指定)。 如果指定型号名称,输出将被限制在该型号上,而不是整个应用程序。
您还可以混合应用程序名称和型号名称。
如果要排除多个应用程序,请不止一次地传递--exclude
:
django-admin dumpdata --exclude=auth --exclude=contenttypes
- 数据库
数据库
¶指定要转储数据的数据库。 默认为default
。
- 天然外国 T0> T1> ¶ T2>
使用natural_key()
模型方法将任何外键和多对多关系序列化到定义该方法的类型的对象。 If
you’re dumping contrib.auth
Permission
objects or
contrib.contenttypes
ContentType
objects, you should probably use this
flag. 有关此和下一个选项的更多详细信息,请参阅natural keys文档。
- 天然初级 T0> T1> ¶ T2>
省略此对象的序列化数据中的主键,因为它可以在反序列化期间计算。
--pks
PRIMARY_KEYS
¶仅输出由逗号分隔的主键列表指定的对象。 这仅在转储一个模型时可用。 默认情况下,输出模型的所有记录。
--output
OUTPUT
,
-o
OUTPUT
¶指定要将序列化数据写入的文件。 默认情况下,数据转到标准输出。
当此选项设置且--verbosity
大于0(默认值)时,终端显示进度条。
flush
¶django-admin flush
¶从数据库中删除所有数据,并重新执行任何后同步处理程序。 已应用迁移的表不会被清除。
如果您希望从空数据库启动并重新运行所有迁移,则应该删除并重新创建数据库,然后再运行migrate
。
- noinput T0>
,
- 无输入 T0> T1> ¶ T2>
禁止所有用户提示。
- 数据库
数据库
¶指定要刷新的数据库。 默认为default
。
inspectdb
¶django-admin inspectdb [table [table ...]]
¶介绍NAME
设置指向的数据库表中的数据库表,并将Django模型模块(models.py
文件)输出到标准输出。 您可以通过将其名称作为参数来选择要检查的表。
如果您有一个旧数据库并想用Django与其交互,请使用此选项。 该脚本将检查数据库并为其中的每个表创建一个模型。
您可能会期望,创建的模型将具有表中每个字段的属性。 请注意,inspectdb
在其字段名称输出中有一些特殊情况:
inspectdb
无法将列类型映射到模型字段类型,则会使用TextField
并插入Python注释'This在字段旁边的字段 类型 是 a 在生成的模型中。
'pass'
, 'class'
or 'for'
), inspectdb
will append
'_field'
to the attribute name. 例如,如果表具有'for'
的列,则生成的模型将具有'for_field'
字段,并设置'for'
属性集到db_column
。 inspectdb
will insert
the Python comment
'Field renamed because it was a Python reserved word.'
next to the
field.此功能意味着作为一个快捷方式,而不是作为明确的模型生成。 运行它之后,您将需要自己查看生成的模型以进行自定义。 特别是,您需要重新排列模型的顺序,以便引用其他模型的模型正确排序。
主键自动对PostgreSQL,MySQL和SQLite进行自动检查,在这种情况下,Django在需要时将primary_key=True
。
inspectdb
适用于PostgreSQL,MySQL和SQLite。 外键检测只适用于PostgreSQL和某些类型的MySQL表。
在模型字段上指定default
时,Django不会创建数据库默认值。
类似地,数据库默认值不会转换为模型字段默认值,也不能通过inspectdb
以任何方式检测。
默认情况下,inspectdb
创建非托管模型。 That is, managed = False
in the model’s Meta
class tells Django not to manage each table’s creation, modification, and deletion. 如果您希望允许Django管理表的生命周期,您需要将managed
选项更改为True
(或者直接删除它,因为True
支持table
参数来选择应检查哪些表。
- 数据库
数据库
¶指定要内省的数据库。 默认为default
。
loaddata
¶django-admin loaddata fixture [fixture ...]
¶搜索并将命名夹具的内容加载到数据库中。
- 数据库
数据库
¶指定要加载数据的数据库。 默认为default
。
- ignorenonexistent T0>
,
-i T0> T1> ¶ T2>
忽略最初生成夹具可能已被删除的字段和模型。
--app
APP_LABEL
¶指定一个应用程序来查找灯具,而不是查看所有应用程序。
- 排除
排除
,
-e
排除
¶不包括从给定应用程序和/或模型(以app_label
或app_label.ModelName
的形式)加载固定装置。 多次使用该选项排除多个应用或模型。
fixture是包含数据库的序列化内容的文件集合。 每个夹具具有唯一的名称,并且包括夹具的文件可以在多个应用中分布在多个目录上。
Django将在三个位置搜索灯具:
fixtures
目录中FIXTURE_DIRS
设置中命名的任何目录中Django将加载它找到的任何和所有的灯具在这些位置匹配提供的灯具名称。
如果命名的夹具具有文件扩展名,则只加载该类型的夹具。 像这样:
django-admin loaddata mydata.json
将只加载名为mydata
的JSON fixture。 fixture扩展名必须与serializer(例如,json
或xml
)的注册名称相对应。
如果你省略扩展,Django将搜索所有可用的灯具类型匹配的夹具。 像这样:
django-admin loaddata mydata
将寻找任何夹具类型称为mydata
。 如果fixture目录包含mydata.json
,则该fixture将作为JSON夹具加载。
命名的灯具可以包括目录组件。 这些目录将包含在搜索路径中。 像这样:
django-admin loaddata foo/bar/mydata.json
将针对每个安装的应用程序搜索<app_label>/fixtures/foo/bar/mydata.json
,foo/bar/mydata.json
在FIXTURE_DIRS
和文本路径<dirname>/foo/bar/mydata.json
中。
当夹具文件被处理时,数据被保存到数据库。
不调用模型定义的save()
方法,并且将使用raw=True
调用任何pre_save
或post_save
>因为实例只包含模型本地的属性。 例如,您可以禁用处理程序访问相关字段,这些字段在夹具加载期间不存在,否则会引发异常:
from django.db.models.signals import post_save
from .models import MyModel
def my_handler(**kwargs):
# disable the handler during fixture loading
if kwargs['raw']:
return
...
post_save.connect(my_handler, sender=MyModel)
你也可以写一个简单的装饰器来封装这个逻辑:
from functools import wraps
def disable_for_loaddata(signal_handler):
"""
Decorator that turns off signal handlers when loading fixture data.
"""
@wraps(signal_handler)
def wrapper(*args, **kwargs):
if kwargs['raw']:
return
signal_handler(*args, **kwargs)
return wrapper
@disable_for_loaddata
def my_handler(**kwargs):
...
请注意,只要灯具反序列化,这个逻辑将禁用信号,而不仅仅是在loaddata
期间。
注意,夹具文件的处理顺序是未定义的。 然而,所有灯具数据被安装为单个事务,因此一个灯具中的数据可以引用另一个灯具中的数据。 如果数据库后端支持行级约束,那么将在事务结束时检查这些约束。
dumpdata
命令可用于为loaddata
生成输入。
灯具可以按zip
,gz
或bz2
格式压缩。 像这样:
django-admin loaddata mydata.json
将查找mydata.json
,mydata.json.zip
,mydata.json.bz2
或mydata.json.gz
。 使用包含在压缩压缩归档文件中的第一个文件。
注意,如果发现两个具有相同名称但不同类型的灯具(例如,如果在同一夹具目录中找到mydata.json
和mydata.xml.gz
),灯具安装将中止,并且调用loaddata
中安装的任何数据将从数据库中删除。
MySQL与MyISAM和fixtures
MySQL的MyISAM存储引擎不支持事务或约束,因此如果您使用MyISAM,您将不会获得夹具数据的验证,或者如果找到多个事务文件,则回滚。
如果您在多数据库设置中,您可能需要将夹具数据加载到一个数据库,但不加载到另一个数据库。 在这种情况下,您可以将数据库标识符添加到您的灯具的名称中。
For example, if your DATABASES
setting has a ‘master’ database
defined, name the fixture mydata.master.json
or
mydata.master.json.gz
and the fixture will only be loaded when you
specify you want to load data into the master
database.
makemessages
¶django-admin makemessages
¶运行在当前目录的整个源树上,并拉出所有标记为要翻译的字符串。 它在conf / locale(在Django树中)或locale(对于项目和应用程序)目录中创建(或更新)消息文件。 更改消息文件后,您需要使用compilemessages
编译它们以与内置gettext支持一起使用。 有关详细信息,请参阅i18n documentation。
此命令不需要配置的设置。 但是,当未配置设置时,该命令不能忽略MEDIA_ROOT
和STATIC_ROOT
目录或包含LOCALE_PATHS
。 它也将以UTF-8编写文件,而不是在FILE_CHARSET
中。
- 均 T0>
,
-a T0> T1> ¶ T2>
更新所有可用语言的消息文件。
- 延期
EXTENSIONS
,
-e
EXTENSIONS
¶Specifies a list of file extensions to examine (default: html
, txt
,
py
or js
if --domain
is js
).
用法示例:
django-admin makemessages --locale=de --extension xhtml
使用逗号分隔多个分机,或多次使用-e
或--extension
django-admin makemessages --locale=de --extension=html,txt --extension xml
--locale
LOCALE
,
-l
LOCALE
¶指定要处理的区域设置。
- 排除
排除
,
-X
排除
¶指定要从处理中排除的区域设置。 如果未提供,则不排除语言环境。
用法示例:
django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
- 域
域
,
-d
域
¶指定消息文件的域。 支持的选项有:
django
对于所有*.py
,*.txt
和*.html
djangojs
用于*.js
文件 - 符号链接 T0>
,
-s T0> T1> ¶ T2>
在寻找新的翻译字符串时,遵循符号链接到目录。
用法示例:
django-admin makemessages --locale=de --symlinks
- 忽视
模式
,
-一世
模式
¶忽略与给定的glob
样式模式匹配的文件或目录。 使用多次忽略更多。
这些模式默认使用:'CVS'
, ”。*”
,'*~'
,'*.pyc'
。
用法示例:
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
- 无 - 缺省 - 忽略 T0> T1> ¶ T2>
禁用默认值--ignore
。
- 无缠绕 T0> T1> ¶ T2>
禁用在语言文件中将长消息行分解成多行。
- 无位置 T0> T1> ¶ T2>
禁止写作“#: 文件名:行
'语言文件中的注释行。
使用此选项可使技术熟练的翻译者更难理解每个消息的上下文。
- 保持罐 T0> T1> ¶ T2>
防止在创建.po
文件之前生成的临时.pot
文件。 这对于调试可能阻止创建最终语言文件的错误非常有用。
请参见
有关如何自定义makemessages
传递到xgettext
的关键字的说明,请参阅Customizing the makemessages command。
makemigrations
¶django-admin makemigrations [app_label [app_label ...]]
¶根据检测到的模型改变创建新的迁移。 迁移与应用程序之间的关系以及更多内容将在the migrations documentation中深入介绍。
提供一个或多个应用程序名称作为参数将限制为指定的应用程序创建的迁移以及所需的任何依赖项(例如,ForeignKey
的另一端的表)。
要将迁移添加到没有migrations
目录的应用程序,请使用应用程序的app_label
运行makemigrations
。
- noinput T0>
,
- 无输入 T0> T1> ¶ T2>
禁止所有用户提示。 如果无法自动解决抑制提示,则命令将退出并显示错误代码3。
- 空 T0> T1> ¶ T2>
输出指定应用程序的空迁移,进行手动编辑。 这适用于高级用户,除非您熟悉迁移格式,迁移操作以及迁移之间的依赖关系,否则不应使用。
- 空转 T0> T1> ¶ T2>
显示在不实际将任何迁移文件写入磁盘的情况下进行迁移。 与 - verbosity 3
一起使用此选项还将显示将要写入的完整迁移文件。
- 合并 T0> T1> ¶ T2>
实现迁移冲突的修复。
- 名称
名称
,
-n
名称
¶允许命名生成的迁移,而不是使用生成的名称。
- 出口 T0>
,
-e T0> T1> ¶ T2>
自1.10版以来已弃用 使用--check
选项。
当没有创建迁移(或者已经创建,如果与--dry-run
组合)时,使makemigrations
退出错误代码1。
- 检查 T0> T1> ¶ T2>
当检测到没有迁移的模型更改时,使makemigrations
退出非零状态。
migrate
¶django-admin migrate [app_label] [migration_name]
¶使数据库状态与当前模型集和迁移集同步。 迁移与应用程序之间的关系以及更多内容将在the migrations documentation中深入介绍。
此命令的行为根据提供的参数而有所不同:
<app_label>
:指定的应用程序运行其迁移,直到最近的迁移。 这可能涉及运行其他应用程序的迁移,由于依赖性。<app_label> <migrationname>
:将数据库模式设置为应用指定迁移的状态,相同的应用程序。 如果之前已迁移过指定的迁移,则可能会导致不应用迁移。 使用名称zero
取消应用应用程序的所有迁移。--database
DATABASE
¶指定要迁移的数据库。 默认为default
。
--fake
¶ 告诉Django将迁移标记为已应用或未应用,但不实际运行SQL以更改数据库模式。
这适用于高级用户如果手动应用更改则直接操作当前的迁移状态;请注意,使用--fake
可能会将迁移状态表置于需要手动恢复以使迁移正常运行的状态。
--fake-initial
¶如果所有具有由该迁移中的所有CreateModel
操作创建的所有模型的名称的数据库表都已存在,则允许Django跳过应用程序的初始迁移。 此选项适用于首次针对预先使用迁移的数据库运行迁移时使用。 但是,此选项不会检查匹配的表名以外的匹配数据库模式,因此只有在您确信现有模式与初始迁移中记录的模式匹配时才能安全使用。
--run-syncdb
¶允许为没有迁移的应用创建表。 虽然不建议这样做,但迁移框架对于具有数百种模型的大型项目来说有时太慢。
--noinput
,
--no-input
¶禁止所有用户提示。 一个示例提示是要求删除陈旧的内容类型。
runserver
¶django-admin runserver [addrport]
¶启用本地上一个轻量级的Web服务器。 默认情况下,服务器运行在IP地址127.0.0.1
的8000端口上。 当然,你也可以显式地传递一个IP地址和端口号给它。
如果您以一个普通用户的身份来运行脚本, 你可能没有权限在低位端口上运行。 低端口数(即1024以下)是预留出来给超级用户(root)的。
这个服务器使用的WSGI application对象是通过在WSGI_APPLICATION
.中的设置指定的
不要在生产环境的设置中使用这个服务器。 他是没有通过安全审查或者性能测试的。 (这是怎么回事。 我们所关心的事情是Web框架而不是Web服务器,所以改进这个服务器使它来达到生产环境的性能已经超出了我们的讨论范围。
如果有需要,每当有访问请求时,这一开发服务器便会自动重新载入代码。 你并不需要在每次代码有变更后重启服务器来使它生效。 然而,一些诸如添加新文件等变更并不会引发服务器的自动重启,所以在这种情况下你仍需手动重启。
如果你使用Linux系统,并且安装了pyinotify,内核信号机制会自动引起开发服务器的重新启动 (而不用每秒去轮询文件的最后更改时间戳)。 这为大型项目提供了更好的扩展,减少了对代码修改的响应时间,更强大的变化检测和电池使用减少。
当你启动服务器之后,在服务器运行过程中每当你的Python代码有变更时,系统的检测框架将会检查整个项目中是否存在一些直观的错误 (参见 check
). 如果检测到了错误,这些错误信息将会输出至标准输出。
只要它们在不同的端口上,就可以运行尽可能多的并发服务器。 多次执行 django-admin runserver
即可
注意默认的IP 127.0.0.1
,它是不可被网络中的其它主机所访问的。 要使您的开发服务器可以查看网络上的其他计算机,请使用自己的IP地址(例如192.168.2.1
)或0.0.0.0
或 ::
(启用IPv6)。
You can provide an IPv6 address surrounded by brackets (e.g. [200a::1]:8000
).你可以使用在括号内使用IPv6地址 This will automatically enable IPv6 support.这样会使ipv6地址自动生效
A hostname containing ASCII-only characters can also be used.也可以使用只包含ASCII的主机名.
如果启用了staticfiles contrib应用程序(在新项目中为默认),则runserver
命令将被其自己的runserver命令覆盖。
如果先前未执行migrate
,则存储迁移历史记录的表在第一次运行runserver
时创建。
记录每个请求和服务器的响应将发送到django.server记录器。
在旧版本中,将日志消息写入sys.stderr
,而不是通过Python日志记录进行处理。
--noreload
¶禁用自动重新加载程序。 这意味着当server开始运行以后,不论你对python代码做了什么修改都不会影响到已经加载到内存中的Python模块.
--nothreading
¶禁用在开发服务器中使用线程。 默认情况下,服务器是多线程的。
--ipv6
,
-6
¶使用IPv6作为开发服务器。 这会将默认的IP地址从127.0.0.1
改为::1
。
端口8000在IP地址127.0.0.1
:
django-admin runserver
端口8000在IP地址1.2.3.4
:
django-admin runserver 1.2.3.4:8000
端口7000在IP地址127.0.0.1
:
django-admin runserver 7000
端口7000在IP地址1.2.3.4
:
django-admin runserver 1.2.3.4:7000
端口8000在IPv6地址::1
:
django-admin runserver -6
IPv6地址::1
:
django-admin runserver -6 7000
端口7000在IPv6地址2001:0db8:1234:5678::9
:
django-admin runserver [2001:0db8:1234:5678::9]:7000
端口8000在主机的IPv4地址localhost
:
django-admin runserver localhost:8000
端口8000在主机的IPv6地址localhost
:
django-admin runserver -6 localhost:8000
默认设置中,开发服务器不会为你的网站提供任何的静态文件(比如CSS 文件, images, MEDIA_URL
下的文件等等). 如果要配置Django来提供静态媒体,请阅读Managing static files (e.g. images, JavaScript, CSS)。
sendtestemail
¶django-admin sendtestemail [email [email ...]]
¶发送测试电子邮件(确认通过Django发送的电子邮件正在工作)给指定的收件人。 像这样:
django-admin sendtestemail foo@example.com bar@example.com
有几个选项,您可以将它们的任意组合使用在一起:
--managers
¶使用mail_managers()
邮寄MANAGERS
中指定的电子邮件地址。
--admins
¶使用mail_admins()
邮寄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,但是想要强制使用“plain”Python解释器,则使用python
作为接口名称,如下所示:
django-admin shell -i python
自1.10版以来已弃用 在旧版本中,使用--plain
选项,而不是-i python
。 这已被弃用,将在Django 2.0中删除。
--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。
在旧版本中,REPL也在UNIX系统上输出。
showmigrations
¶django-admin showmigrations [app_label [app_label ...]]
¶展示项目中所有的迁移 您可以选择以下两种格式之一:
--list
,
-l
¶列出Django知道的所有应用程序,每个应用程序可用的迁移以及是否应用每个迁移(在迁移名称旁边标有[X]
)。
还列出了尚未迁移的应用,但已打印(无 迁移)
。
这是默认的输出格式。
--plan
,
-p
¶显示Django将应用迁移的迁移计划。 如--list
,应用的迁移由[X]
标记。 对于及以上的--verbosity
,还会显示迁移的所有依赖关系。
app_label
的参数限制输出,但是,还可以包含提供的应用程序的依赖关系。
在旧版本中,showmigrations - plan
忽略应用标签。
--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,这将修复序列与其自动递增的字段数据不同步的情况。
--database
DATABASE
¶指定打印SQL的数据库。 默认为default
。
squashmigrations
¶django-admin squashmigrations app_label [start_migration_name] migration_name
¶将app_label
的迁移(包括migration_name
)迁移到较少的迁移中(如果可能)。 由此造成的被挤压的迁移可以安全地与未被挖掘的迁移。 有关详细信息,请参阅Squashing migrations。
当给出start_migration_name
时,Django将仅包括从此迁移开始并包括迁移的迁移。 这有助于缓解RunPython
和django.db.migrations.operations.RunSQL
迁移操作的挤压限制。
--no-optimize
¶生成压缩的迁移时禁用优化器。 默认情况下,Django将尝试优化迁移中的操作,以减少生成的文件的大小。 如果此过程失败或创建不正确的迁移,请使用此选项,但是也请提供有关该行为的Django错误报告,因为优化是安全的。
--noinput
,
--no-input
¶禁止所有用户提示。
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
文件后缀
,
-e
文件后缀
¶指定使用模板引擎应用程序模板中的哪些文件扩展名。 默认为py
。
--name
文件
,
-n
文件
¶指定应用程序模板中的哪些文件(与--extension
匹配的文件)应与模板引擎一起呈现。 默认为空列表。
用于所有匹配文件的template context
startapp
命令的任何选项(在命令支持的选项之间)app_name
- 传递给命令的应用程序名称app_directory
- 新创建的应用程序的完整路径camel_case_app_name
- 骆驼案例格式的应用程序名称docs_version
- 文档版本:'dev'
或'1.x'
警告
当使用Django模板引擎(默认情况下,所有*.py
文件)呈现应用程序模板文件时,Django也将替换所有包含的模板变量。 例如,如果其中一个Python文件包含解释与模板呈现相关的特定功能的docstring,则可能会导致不正确的示例。
要解决此问题,您可以使用templatetag
模板标签来“转义”模板语法的各个部分。
In addition, to allow Python template files that contain Django template
language syntax while also preventing packaging systems from trying to
byte-compile invalid *.py
files, template files ending with .py-tpl
will be renamed to .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
- 模板
模板
¶指定自定义项目模板的目录,文件路径或URL。 有关示例和用法,请参阅startapp --template
文档。
- 延期
EXTENSIONS
,
-e
EXTENSIONS
¶指定项目模板中应使用模板引擎呈现哪些文件扩展名。 默认为py
。
- 名称
FILES
,
-n
FILES
¶指定项目模板中的哪些文件(除了匹配--extension
之外)应该使用模板引擎来呈现。 默认为空列表。
startproject
命令的任何选项(在命令支持的选项之间)project_name
- 传递给命令的项目名称project_directory
- 新创建项目的完整路径secret_key
- SECRET_KEY
设置的随机密钥docs_version
- 文档版本:'dev'
或'1.x'
另请参阅startapp
中提及的rendering warning。
test
¶django-admin test [test_label [test_label ...]]
¶运行所有已安装应用程序的测试。 有关详细信息,请参阅Testing in Django。
- FAILFAST T0> T1> ¶ T2>
停止运行测试并在测试失败后立即报告故障。
--testrunner
的TestRunner
¶控制用于执行测试的测试运行器类。 该值将覆盖由TEST_RUNNER
设置提供的值。
- noinput T0>
,
- 无输入 T0> T1> ¶ T2>
禁止所有用户提示。 典型的提示是关于删除现有测试数据库的警告。
test
命令代表指定的--testrunner
接收选项。 这些是默认测试运行器的选项:DiscoverRunner
。
- keepdb T0>
,
-k T0> T1> ¶ T2>
在测试运行之间保留测试数据库。 这具有跳过创建和销毁动作的优点,这可以大大减少运行测试的时间,特别是在大型测试套件中的测试。 如果测试数据库不存在,它将在第一次运行时创建,然后保存用于每次后续运行。 任何未应用的迁移也将在运行测试套件之前应用于测试数据库。
- 反 T0>
,
-r T0> T1> ¶ T2>
以相反的执行顺序排序测试用例。 这可能有助于调试未正确隔离的测试的副作用。 使用此选项时,将保留Grouping by test class。
- 调试模式 T0> T1> ¶ T2>
在运行测试之前,将DEBUG
设置设置为True
。 这可能有助于排除测试失败。
- 调试-SQL T0>
,
-d T0> T1> ¶ T2>
启用SQL logging失败的测试。 如果--verbosity
是2
,那么也会输出通过测试的查询。
- 平行
[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可能无法显示异常追溯。 这可以使调试变得困难。 如果遇到此问题,请运行受影响的测试而不进行并行化以查看故障的回溯。
这是一个已知的限制。 它源于需要序列化对象以便在进程之间进行交换。 看到 什么可以腌和无led? 详细信息。
- 标签
TAGS
¶只运行标有的marked with the specified tags
可以多次指定,并结合test --exclude-tag
。
- 排除标记
EXCLUDE_TAGS
¶不包含用指定的标签标记的测试marked with the specified tags
可以指定多次,并结合test --tag
。
testserver
¶django-admin testserver [fixture [fixture ...]]
¶使用给定fixture的数据运行Django开发服务器(如runserver
)。
例如,此命令:
django-admin testserver mydata.json
...将执行以下步骤:
loaddata
的文档。)runserver
),指向此新创建的测试数据库,而不是生产数据库。这在许多方面是有用的:
testserver
手动与Web浏览器中的视图进行交互。dumpdata
命令,如上所述),然后使用testserver
运行带有该数据的Web应用程序。
有了这个安排,你有以任何方式混乱你的数据的灵活性,知道你正在做的任何数据更改只是对一个测试数据库。请注意,该服务器不自动检测您的Python源代码的更改(如runserver
)。 但它会检测对模板的更改。
--addrport
ADDRPORT
¶指定与默认值127.0.0.1:8000
不同的端口或IP地址和端口。 此值遵循完全相同的格式,并且具有与runserver
命令的参数完全相同的功能。
例子:
要使用fixture1
和fixture2
在端口7000上运行测试服务器:
django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000
(上面的语句是等价的。 我们包括它们两者,以证明选项在fixture参数之前或之后是无关紧要的。)
使用test
灯具在1.2.3.4:7000上运行:
django-admin testserver --addrport 1.2.3.4:7000 test
- noinput T0>
,
- 无输入 T0> T1> ¶ T2>
禁止所有用户提示。 典型的提示是关于删除现有测试数据库的警告。
一些命令仅在implements的django.contrib
应用程序已启用enabled
时可用。 本节按照其应用程序对它们进行分组。
django.contrib.auth
¶changepassword
¶django-admin changepassword [&lt; username&gt;]
¶此命令仅在安装了Django的authentication system(django.contrib.auth
)时可用。
允许更改用户的密码。 它会提示您为给定用户输入两次新密码。 如果条目相同,则立即成为新密码。 如果您不提供用户,该命令将尝试更改其用户名与当前用户名匹配的密码。
- 数据库
数据库
¶指定要查询用户的数据库。 默认为default
。
用法示例:
django-admin changepassword ringo
createsuperuser
¶django-admin creationuperuser
¶此命令仅在安装了Django的authentication system(django.contrib.auth
)时可用。
创建超级用户帐户(具有所有权限的用户)。 如果您需要创建初始超级用户帐户,或者需要以编程方式为您的网站生成超级用户帐户,这将非常有用。
以交互方式运行时,此命令将提示输入新超级用户帐户的密码。 当以非交互方式运行时,将不会设置密码,并且超级用户帐户将无法登录,直到为其手动设置密码。
- 用户名
用户名
¶ - 电子邮件
电子邮件
¶可以使用命令行上的--username
和--email
参数提供新帐户的用户名和电子邮件地址。 如果未提供其中任何一个,则createsuperuser
将在以交互方式运行时提示输入。
- 数据库
数据库
¶指定将保存超级用户对象的数据库。
如果要自定义数据输入和验证,可以对管理命令进行子类化,并覆盖get_input_data()
。 有关现有实现和方法参数的详细信息,请参阅源代码。 例如,如果您在REQUIRED_FIELDS
中有ForeignKey
,并且希望允许创建实例而不是输入现有实例的主键,那么这将非常有用。
django.contrib.contenttypes
¶remove_stale_contenttypes
¶django-admin remove_stale_contenttypes
¶此命令仅在安装了Django的contenttypes app(django.contrib.contenttypes
)时可用。
从数据库中删除陈旧的内容类型(从已删除的模型)。 依赖于已删除内容类型的任何对象也将被删除。 在确认可以继续删除之前,将显示已删除对象的列表。
- 数据库
数据库
¶指定要使用的数据库。 默认为default
。
django.contrib.gis
¶django.contrib.sitemaps
¶django.contrib.staticfiles
¶collectstatic
¶仅当安装了static files application(django.contrib.staticfiles
)时,此命令才可用。
请参阅staticfiles文档中的description
。
findstatic
¶仅当安装了static files application(django.contrib.staticfiles
)时,此命令才可用。
请参阅staticfiles文档中的description
。
虽然一些命令可能允许自己的自定义选项,但每个命令允许以下选项:
--pythonpath
PYTHONPATH
¶将给定的文件系统路径添加到Python 导入搜索路径。 如果未提供,django-admin
将使用PYTHONPATH
环境变量。
此选项在manage.py
中是不必要的,因为它需要为您设置Python路径。
用法示例:
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
--settings
设置
¶指定要使用的设置模块。 设置模块应该是Python包语法,例如。 mysite.settings
。 如果未提供,django-admin
将使用DJANGO_SETTINGS_MODULE
环境变量。
这个选项在manage.py
中是不必要的,因为它默认使用当前项目的settings.py
。
用法示例:
django-admin migrate --settings=mysite.settings
- 回溯 T0> T1> ¶ T2>
当引发CommandError
时,显示完整的堆栈跟踪。 默认情况下,当CommandError
发生时,django-admin
将显示一个简单的错误消息,也可能是任何其他异常的完整堆栈跟踪。
用法示例:
django-admin migrate --traceback
--verbosity
{0,1,2,3}
,
-v
{0,1,2,3}
¶指定命令应该向控制台打印的通知和调试信息量。
0
表示无输出。1
表示正常输出(默认)。2
表示详细输出。3
表示非常详细输出。用法示例:
django-admin migrate --verbosity 2
- 无色 T0> T1> ¶ T2>
禁用彩色命令输出。 一些命令将其输出格式化为着色。 例如,错误将以红色打印到控制台,SQL语句将突出显示语法。
用法示例:
django-admin runserver --no-color
如果您的终端支持ANSI颜色输出,则django-admin
/ manage.py
命令将使用漂亮的颜色编码输出。 如果你将命令的输出传递到另一个程序,它不会使用颜色代码。
在Windows下,本机控制台不支持ANSI转义序列,因此默认情况下没有颜色输出。 但是,您可以安装ANSICON第三方工具,Django命令将检测其存在,并将使用其服务的颜色输出,就像在基于Unix的平台上。
用于语法高亮的颜色可以自定义。 Django附带三个调色板:
dark
,适用于在黑色背景上显示白色文字的端子。 这是默认调色板。light
,适用于在白色背景上显示黑色文本的终端。nocolor
,禁用语法高亮显示。您可以通过设置DJANGO_COLORS
环境变量来指定要使用的调色板来选择调色板。 例如,要在Unix或OS / X BASH shell下指定light
选项板,您将在命令提示符下运行以下命令:
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成功服务器响应。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 Server错误响应。migrate_heading
- 迁移管理命令中的标题。migrate_label
- 迁移名称。可以从以下列表中为这些角色中的每个角色分配特定的前景和背景颜色:
黑色
红
绿色
黄色
蓝色
品红
青色
白色
然后可以使用以下显示选项修改每种颜色:
胆大
下划线
眨
相反
隐藏
颜色规范遵循以下模式之一:
角色= FG
角色= FG / BG
角色= FG,期权,期权
角色= FG / BG,期权,期权
其中role
是有效颜色角色的名称,fg
是前景颜色,bg
是背景颜色,每个option
然后用分号分隔多个颜色规格。 像这样:
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
将指定使用蓝色闪烁的黄色显示错误,并使用品红色显示通知。 所有其他颜色的角色将保持不着色。
也可以通过扩展基本调色板来指定颜色。 如果您在颜色规范中放置调色板名称,则该调色板隐含的所有颜色将被加载。 所以:
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
将指定使用浅色调调色板中的所有颜色,除了用于将按指定重写的错误和通知的颜色。
如果使用Bash shell,请考虑安装Django bash完成脚本,该脚本位于Django发行版中的extras/django_bash_completion
中。 它允许django-admin
和manage.py
命令的选项卡完成,所以你可以,例如...
django-admin
。sql
,然后选择[TAB],以查看其名称以sql
开头的所有可用选项。有关如何添加自定义操作,请参阅Writing custom django-admin commands。
django.core.management。
call_command
(name,* args,** options)¶要从代码使用call_command
调用管理命令。
名称
* ARGS
call_command('flush', ' - verbosity = 0')
。**选项
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 creationuperuser - 无输入
转换为call_command 'creationuperuser', interactive = False)
。 要找到要用于call_command()
的关键字参数名称,请检查传递给parser.add_argument()
的dest
参数的命令源代码。
采用多个选项的命令选项传递列表:
management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
call_command()
函数的返回值与命令的handle()
方法的返回值相同。
call_command()
现在返回从command.handle()
方法接收的值。 它现在也接受一个命令对象作为第一个参数。
请注意,您可以重定向标准输出和错误流,因为所有命令都支持stdout
和stderr
选项。 例如,您可以写:
with open('/path/to/command_output') as f:
management.call_command('dumpdata', stdout=f)
2017年9月6日