django-adminmanage.py

django-admin is Django’s command-line utility for administrative tasks. 本文件概述了它可以做的所有事情。

另外,每个Django项目中都会自动创建manage.py manage.py完成与django-admin完全相同的功能,但是会为您处理几件事情:

  • 它把你的项目的包放在sys.path上。
  • 它设置 DJANGO_SETTINGS_MODULE环境变量,使其指向您的项目的settings.py文件。

如果您通过setup.py实用程序安装了Django,那么django-admin脚本应该位于系统路径中。 如果不在你的路径上,你可以在你的Python安装目录下的site-packages/django/bin中找到它。 考虑从路径上的某个地方对它进行符号链接,比如/usr/local/bin

对于没有可用的符号链接功能的Windows用户,您可以将django-admin.exe复制到现有路径的某个位置,或编辑PATH设置 设置 - 控制 面板 - 系统 - 高级 - 环境...)指向它的安装位置。

通常,在单个Django项目上工作时,比django-admin更易于使用manage.py If you need to switch between multiple Django settings files, use django-admin with DJANGO_SETTINGS_MODULE or the --settings command line option.

The command-line examples throughout this document use django-admin to be consistent, but any example can use manage.py or python -m django just as well.

用法¶ T0>

$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]

command应该是本文档中列出的命令之一。 可选的options应该是给定命令可用的零个或多个选项。

获得运行时帮助

django-admin帮助

运行django-admin help来显示使用信息和每个应用程序提供的命令列表。

运行django-admin 帮助 - 命令来显示所有可用命令的列表。

运行django-admin 帮助 &lt; tgt;&gt;显示给定命令的描述和其列表可用选项。

应用程序名称

许多命令都带有“应用程序名称”列表。“应用程序名称”是包含模型的软件包的基本名称。 例如,如果您的INSTALLED_APPS包含字符串'mysite.blog',则应用程序名称为blog

确定版本

django-admin版本

运行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

系统检查框架执行许多不同类型的检查,这些检查categorized with tags分类。 您可以使用这些标签来限制对特定类别的检查。 例如,要仅执行模型和兼容性检查,请运行:

django-admin check --tag models --tag compatibility
- 列表标记 T0> T1> ¶ T2>

列出所有可用的标签。

- 部署 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 dbshel​​l

运行ENGINE设置中指定的数据库引擎的命令行客户端,并使用USERPASSWORD等中指定的连接参数,设置。

  • 对于PostgreSQL,这将运行psql命令行客户端。
  • 对于MySQL,这将运行mysql命令行客户端。
  • 对于SQLite,这将运行sqlite3命令行客户端。
  • 对于Oracle,这将运行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指定的另一个设置文件)之间的差异。

没有出现在默认设置中的设置后面是"###" For example, the default settings don’t define ROOT_URLCONF, so ROOT_URLCONF is followed by "###" in the output of diffsettings.

- 均 T0> T1> ¶ T2>

显示所有设置,即使它们具有Django的默认值。 这样的设置以"###"为前缀。

- 默认 MODULE
Django 1.11新增功能

设置模块比较当前的设置。 留空以与Django的默认设置进行比较。

--output {哈希,统一}
Django 2.0新增功能

指定输出格式。 可用的值是hashunified hash is the default mode that displays the output that’s described above. unified显示与diff -u类似的输出。 默认设置以负号为前缀,然后是带有加号前缀的更改设置。

dumpdata

django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]

输出到标准输出与指定应用程序相关联的数据库中的所有数据。

如果没有提供应用程序名称,则所有已安装的应用程序都将被转储。

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()模型方法将任何外键和多对多关系序列化为定义该方法的类型的对象。 如果您正在倾销contrib.auth Permission对象或contrib.contenttypes ContentType对象,则应该使用此旗。 请参阅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在其字段名称输出中有一些特殊情况:

  • If inspectdb cannot map a column’s type to a model field type, it’ll use TextField and will insert the Python comment 'This field type is a guess.' next to the field in the generated model. 已识别的字段可能取决于INSTALLED_APPS中列出的应用程序。 例如,django.contrib.postgres为几个特定于PostgreSQL的字段类型添加了识别功能。
  • If the database column name is a Python reserved word (such as 'pass', 'class' or 'for'), inspectdb will append '_field' to the attribute name. For example, if a table has a column 'for', the generated model will have a field 'for_field', with the db_column attribute set to 'for'. 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 works with PostgreSQL, MySQL and 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

- 数据库 数据库

指定要内省的数据库。 默认为default

loaddata

django-admin loaddata fixture [fixture ...]

搜索并将指定的灯具的内容加载到数据库中。

- 数据库 数据库

指定要将数据加载到的数据库。 默认为default

- ignorenonexistent T0>, -i T0> T1> ¶ T2>

忽略最初生成灯具后可能已被删除的字段和模型。

--app APP_LABEL

指定一个应用程序来查找夹具,而不是查看所有的应用程序。

- 格式 格式
Django 2.0新增功能

Specifies the serialization format (e.g., json or xml) for fixtures read from stdin.

- 排除 排除, -e 排除
Django 1.11新增功能

不包括从给定应用程序和/或模型(以app_labelapp_label.ModelName的形式)加载灯具。 多次使用该选项可排除多个应用程序或模型。

什么是“夹具”?

一个夹具是包含数据库序列化内容的文件集合。 每个灯具都有一个唯一的名称,构成灯具的文件可以分布在多个应用程序的多个目录中。

Django将在三个地方搜索装置:

  1. 在每个安装的应用程序的fixtures目录中
  2. FIXTURE_DIRS设置中命名的任何目录中
  3. 在夹具命名的文字路径中

Django将加载它在这些位置找到的与所提供灯具名称匹配的所有灯具。

如果指定的灯具具有文件扩展名,则只加载该类型的灯具。 例如:

django-admin loaddata mydata.json

只会加载名为mydata的JSON装置。 夹具扩展必须对应于serializer的注册名称(例如jsonxml)。

如果你省略了扩展,Django将会搜索所有可用的灯具类型来匹配灯具。 例如:

django-admin loaddata mydata

将寻找任何称为mydata的夹具类型的夹具。 如果夹具目录包含mydata.json,则该夹具将作为JSON夹具加载。

被命名的灯具可以包含目录组件。 这些目录将被包含在搜索路径中。 例如:

django-admin loaddata foo/bar/mydata.json

会为每个安装的应用程序搜索<app_label>/fixtures/foo/bar/mydata.json,为每个目录搜索<dirname>/foo/bar/mydata.jsonFIXTURE_DIRS中,以及文字路径foo/bar/mydata.json

处理夹具文件时,数据按原样保存到数据库中。 Model defined save() methods are not called, and any pre_save or post_save signals will be called with raw=True since the instance only contains attributes that are local to the model. 例如,您可能想要禁用处理程序访问夹具加载期间不存在的相关字段,否则会引发异常:

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生成输入。

压缩的装置

夹具可能以zipgzbz2格式压缩。 例如:

django-admin loaddata mydata.json

会查找任何mydata.jsonmydata.json.zipmydata.json.gzmydata.json.bz2 包含在zip压缩归档中的第一个文件被使用。

请注意,如果发现两个具有相同名称但夹具类型不同的灯具(例如,如果在同一灯具目录中找到mydata.jsonmydata.xml.gz ),夹具安装将被中止,并且在loaddata调用中安装的任何数据将从数据库中移除。

MySQL与MyISAM和灯具

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.

stdin

Django 2.0新增功能

您可以使用破折号作为夹具名称来加载sys.stdin中的输入。 例如:

django-admin loaddata --format=json -

When reading from stdin, the --format option is required to specify the serialization format of the input (e.g., json or xml).

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进行编译,以便与内置的gettext支持一起使用。 See the i18n documentation for details.

该命令不需要配置设置。 但是,如果未配置设置,则该命令不能忽略MEDIA_ROOTSTATIC_ROOT目录或包含LOCALE_PATHS It will also write files in UTF-8 rather than in 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 for all *.py, *.html and *.txt files (default)
  • djangojs代表*.js文件

在查找新的翻译字符串时,遵循符号链接到目录。

用法示例:

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>

抑制写作'#: 文件名:行语言文件中的注释行。 使用此选项使技术熟练的翻译人员难以理解每个消息的上下文。

- 添加位置 [{完整,文件,从来没有}]
Django 2.0新增功能

控制 #: 文件名:行 语言文件中的注释行。 如果选项是:

  • full (the default if not given): the lines include both file name and line number.
  • file:行号被省略。
  • never:行被压缩(与--no-location相同)。

需要gettext 0.19或更新。

- 保持罐 T0> T1> ¶ T2>

防止在创建.po文件之前删除生成的临时.pot文件。 这对于调试可能阻止最终语言文件被创建的错误很有用。

也可以看看

有关如何自定义makemessages传递给xgettext的关键字,请参阅Customizing the makemessages command

makemigrations

django-admin makemigrations [app_label [app_label ...]]

根据检测到的变化创建新的迁移。 Migrations, their relationship with apps and more are covered in depth in the migrations documentation.

提供一个或多个应用程序名称作为参数将限制为指定的应用程序创建的迁移以及所需的任何依赖关系(例如,在ForeignKey的另一端的表)。

要将迁移添加到没有migrations目录的应用程序,请使用应用程序的app_label运行makemigrations

- noinput T0>, - 无输入 T0> T1> ¶ T2>

禁止所有用户提示。 如果被禁止的提示符不能自动解析,则该命令将以错误代码3退出。

- 空 T0> T1> ¶ T2>

输出指定应用程序的空迁移,以进行手动编辑。 这适用于高级用户,除非您熟悉迁移格式,迁移操作以及迁移之间的依赖关系,否则不应使用它。

- 空转 T0> T1> ¶ T2>

显示在没有将任何迁移文件写入磁盘的情况下进行的迁移。 使用这个选项和 - 详细程度 3也会显示完整的将被写入的迁移文件。

- 合并 T0> T1> ¶ T2>

启用修复迁移冲突。

- 名称 名称, -n 名称

允许命名生成的迁移,而不是使用生成的名称。

当没有创建迁移时(或者已经创建,如果与--dry-run结合)),使makemigrations退出并显示错误代码1。

- 检查 T0> T1> ¶ T2>

Makes makemigrations exit with a non-zero status when model changes without migrations are detected.

migrate

django-admin迁移[app_label] [migration_name]

将数据库状态与当前一组模型和迁移同步。 Migrations, their relationship with apps and more are covered in depth in the migrations documentation.

该命令的行为根据提供的参数而变化:

  • 没有参数:所有应用程序都运行了所有的迁移。
  • <app_label>:指定的应用程序已经迁移,直到最近的迁移。 这可能涉及运行其他应用程序的迁移,由于依赖关系。
  • <app_label> <migrationname>: Brings the database schema to a state where the named migration is applied, but no later migrations in the same app are applied. 如果您之前已迁移过指定的迁移,则可能涉及到不应用迁移。 使用名称zero来取消应用程序的所有迁移。
- 数据库 数据库

指定要迁移的数据库。 默认为default

- 假 T0> T1> ¶ T2>

告诉Django将迁移标记为已应用或未应用,但实际上并未运行SQL来更改数据库模式。

这适用于高级用户直接操作当前的迁移状态,如果他们手动应用更改;需要注意的是,使用--fake存在将迁移状态表置于需要手动恢复才能使迁移正常运行的风险。

- 假初始 T0> T1> ¶ T2>

允许Django跳过应用程序的初始迁移,如果所有具有由该迁移中的所有CreateModel操作创建的所有模型的名称的数据库表已经存在。 此选项用于首次针对预先使用迁移的数据库运行迁移时使用。 但是,此选项不会检查匹配表名称以外的匹配数据库模式,因此只有在确信现有模式与初始迁移中记录的内容匹配的情况下才可以使用。

- 运行执行syncdb T0> T1> ¶ T2>

允许在没有迁移的情况下为应用创建表格。 虽然不建议这样做,但对于拥有数百个模型的大型项目,迁移框架有时过于缓慢。

- noinput T0>, - 无输入 T0> T1> ¶ T2>

禁止所有用户提示。 示例提示是询问有关删除陈旧的内容类型。

runserver

django-admin runserver [addrport]

在本地机器上启动一个轻量级开发Web服务器。 默认情况下,服务器在IP地址127.0.0.1上的端口8000上运行。 您可以显式传入IP地址和端口号。

如果以具有普通权限的用户身份运行此脚本(推荐),则可能无法访问低端口号的端口。 低端口号是为超级用户(root)保留的。

此服务器使用由WSGI_APPLICATION设置指定的WSGI应用程序对象。

请勿在生产环境中使用此服务器。 它没有经过安全审计或性能测试。 (这就是它会留下来的。 我们在做Web框架,而不是Web服务器,所以改进这个服务器能够处理生产环境不在Django的范围之内。)

开发服务器根据需要自动为每个请求重新加载Python代码。 您不需要重新启动服务器以使代码更改生效。 但是,添加文件等一些操作不会触发重新启动,因此在这种情况下您必须重新启动服务器。

如果您正在使用Linux并安装pyinotify,内核信号将用于自动重新加载服务器(而不是每秒轮询文件修改时间戳)。 这为大型项目提供了更好的扩展性,缩短了代码修改的响应时间,更强大的更改检测以及电池使用率降低。

当你启动服务器时,每次在服务器运行的时候改变Python代码,系统检查框架都会检查你的整个Django项目的一些常见错误(参见check命令)。 如果发现任何错误,它们将被打印到标准输出。

只要在不同的端口上,您可以根据需要运行尽可能多的并发服务器。 只需多次执行django-admin runserver即可。

请注意,默认IP地址127.0.0.1不能从网络上的其他计算机访问。 要使开发服务器可以在网络上的其他机器上查看,请使用自己的IP地址(例如192.168.2.1)或0.0.0.0 :: (启用了IPv6)。

您可以提供括号括起来的IPv6地址(例如[200a::1]:8000)。 这将自动启用IPv6支持。

还可以使用包含仅ASCII字符的主机名。

如果启用了staticfiles contrib应用程序(在新项目中默认),runserver命令将被其自己的runserver命令覆盖。

记录每个请求和服务器的响应被发送到django.server记录器。

- noreload T0> T1> ¶ T2>

禁用自动重新加载器。 这意味着当服务器运行时你所做的任何Python代码更改,如果特定的Python模块已经被加载到内存中,not将会生效。

- nothreading T0> T1> ¶ T2>

禁用在开发服务器中使用线程。 该服务器默认为多线程。

- IPv6的 T0>, -6 T0> T1> ¶ T2>

将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

端口7000上的IPv6地址::1

django-admin runserver -6 7000

端口7000上的IPv6地址2001:0db8:1234:5678::9

django-admin runserver [2001:0db8:1234:5678::9]:7000

主机的IPv4地址上的端口8000 localhost

django-admin runserver localhost:8000

端口8000上的主机的IPv6地址localhost

django-admin runserver -6 localhost:8000

使用开发服务器提供静态文件

默认情况下,开发服务器不会为您的站点提供任何静态文件(比如CSS文件,图片,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

有几个选项,你可以使用它们的任意组合:

- 管理者 T0> T1> ¶ T2>

使用mail_managers()邮寄MANAGERS中指定的电子邮件地址。

- 管理员 T0> T1> ¶ T2>

使用mail_admins()邮寄在ADMINS中指定的电子邮件地址。

shell

django-admin shell

启动Python交互式解释器。

- 接口 {IPython中,bpython,蟒}, -一世 {IPython中,bpython,蟒}

指定要使用的外壳。 默认情况下,如果安装了Django,则会使用IPythonbpython 如果两者均已安装,请指定您想要的那个:

IPython的:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

如果你安装了一个“丰富”的shell,但是想强制使用“简单的”Python解释器,那么使用python作为接口名称,如下所示:

django-admin shell -i python
- nostartup T0> T1> ¶ T2>

禁止阅读“普通”Python解释器的启动脚本。 默认情况下,读取由 PYTHONSTARTUP环境变量或~/.pythonrc.py脚本指向的脚本。

- 命令 命令, -C 命令

让您将一个命令作为字符串传递给Django,如下所示:

django-admin shell --command="import django; print(django.__version__)"

你也可以在标准输入中传递代码来执行它。 例如:

$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF

在Windows上,由于该平台上的select.select()的实现限制,REPL被输出。

在Django 1.11中更改:

在旧版本中,REPL也在UNIX系统上输出。

showmigrations

django-admin showmigrations [app_label [app_label ...]]

显示项目中的所有迁移。 您可以选择两种格式之一:

- 列表 T0>, -l T1> ¶ T2>

列出Django知道的所有应用程序,每个应用程序的可用迁移以及是否应用每个迁移(通过迁移名称旁边的[X]标记)。

没有迁移的应用程序也被列出,但是在它们下面打印了(no migrations)

这是默认的输出格式。

- 计划 T0>, -p T0> T1> ¶ T2>

显示Django将应用迁移的迁移计划。 --list一样,应用的迁移由[X]标记。 对于2或更高的--verbosity,也会显示迁移的所有依赖关系。

app_labels arguments limit the output, however, dependencies of provided apps may also be included.

在Django 1.11中更改:

在较早的版本中,showmigrations - plan会忽略应用标签。

- 数据库 数据库

指定要检查的数据库。 默认为default

sqlflush

django-admin sqlflush

打印将为flush命令执行的SQL语句。

- 数据库 数据库

指定要为其打印SQL的数据库。 默认为default

sqlmigrate

django-admin sqlmigrate app_label migration_name

打印指定迁移的SQL。 这需要一个活动的数据库连接,它将用来解析约束名称;这意味着您必须针对您希望稍后应用的数据库副本生成SQL。

请注意,sqlmigrate不会为其输出着色。

- 向后 T0> T1> ¶ T2>

生成不适用迁移的SQL。 默认情况下,创建的SQL用于在前进方向上运行迁移。

- 数据库 数据库

指定要为其生成SQL的数据库。 默认为default

sqlsequencereset

django-admin sqlsequencereset app_label [app_label ...]

打印SQL语句以重置给定应用程序名称的序列。

序列是一些数据库引擎使用的索引,用于跟踪自动递增字段的下一个可用编号。

使用此命令来生成SQL,这将修复序列与其自动递增的字段数据不同步的情况。

- 数据库 数据库

指定要为其打印SQL的数据库。 默认为default

squashmigrations

django-admin squashmigrations app_label [start_migration_name] migration_name

如果可能的话,将app_label最多包括migration_name的迁移压缩到更少的迁移中。 由此产生的挤压移动可以安全地与没有晃动的移动一起居住。 有关更多信息,请阅读Squashing migrations

当给出start_migration_name时,Django将只包含从此迁移开始的迁移。 这有助于缓解RunPythondjango.db.migrations.operations.RunSQL迁移操作的挤压限制。

- 无优化 T0> T1> ¶ T2>

生成压缩迁移时禁用优化器。 默认情况下,Django将尝试优化您的迁移中的操作,以减少生成文件的大小。 如果此过程失败或创建不正确的迁移,请使用此选项,但也请提交有关此行为的Django错误报告,因为优化是安全的。

- noinput T0>, - 无输入 T0> T1> ¶ T2>

禁止所有用户提示。

--squashed名 SQUASHED_NAME
Django 2.0新增功能

设置压扁的迁移的名称。 省略时,名称以第一次和最后一次迁移为基础,中间有_squashed_

startapp

django-admin startapp name [目录]

为当前目录或给定目标中的给定应用程序名称创建一个Django应用程序目录结构。

默认情况下,创建的目录包含models.py文件和其他应用程序模板文件。 (有关更多详细信息,请参见)。 如果只给出应用程序名称,则应用程序目录将在当前工作目录中创建。

如果提供了可选的目的地,Django将使用该现有的目录,而不是创建一个新目录。 您可以使用'。'来表示当前的工作目录。

例如:

django-admin startapp myapp /Users/jezdez/Code/myapp
- 模板 模板

Provides the path to a directory with a custom app template file or a path to a compressed file (.tar.gz, .tar.bz2, .tgz, .tbz, .zip) containing the app template files.

例如,在创建myapp应用程序时,这将在给定目录中查找应用程序模板:

django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp

Django还将接受URL(httphttpsftp)到应用程序模板文件的压缩存档,

例如,利用GitHub的功能将存储库作为zip文件公开,您可以使用如下URL:

django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
- 延期 EXTENSIONS, -e EXTENSIONS

指定应使用模板引擎呈现应用模板中的哪些文件扩展名。 默认为py

- 名称 FILES, -n FILES

指定应用模板中的哪些文件(除了匹配--extension的那些文件)应该使用模板引擎呈现。 默认为一个空的列表。

用于所有匹配文件的template context是:

  • 传递给startapp命令的任何选项(在命令支持的选项中)
  • app_name – the app name as passed to the command
  • app_directory - 新建应用的完整路径
  • camel_case_app_name – the app name in camel case format
  • docs_version – the version of the documentation: 'dev' or '1.x'

警告

当使用Django模板引擎(默认情况下,所有的*.py文件)呈现应用程序模板文件时,Django也将替换所有包含的杂散模板变量。 例如,如果其中一个Python文件包含解释与模板呈现相关的特定功能的文档字符串,则可能会导致错误的示例。

要解决此问题,可以使用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的那些文件)。 默认为一个空的列表。

使用的template context是:

  • 传递给startproject命令的任何选项(在命令支持的选项中)
  • project_name – the project name as passed to the command
  • project_directory - 新建项目的完整路径
  • secret_key – a random key for the SECRET_KEY setting
  • docs_version – the version of the documentation: 'dev' or '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>
Django 1.11新增功能

在运行测试之前将DEBUG设置设置为True 这可能有助于排除测试故障。

- 调试-SQL T0>, -d T0> T1> ¶ T2>

启用SQL logging进行失败的测试。 如果--verbosity2,那么也会输出通过测试的查询。

- 平行 [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可能无法显示异常回溯。 这可能会使调试变得困难。 如果遇到此问题,请在不进行并行化的情况下运行受影响的测试,以查看失败的追溯。

这是一个已知的限制。 它需要序列化对象以便在进程之间交换对象。 看到 什么可以腌渍和unpickled? 了解详情。

- 标签 TAGS

只运行标有指定标签的测试marked with the specified tags 可以指定多次,并与test --exclude-tag结合使用。

- 排除标记 EXCLUDE_TAGS

排除标有指定标签的测试marked with the specified tags 可以指定多次,并与test --tag结合使用。

testserver

django-admin testserver [fixture [fixture ...]]

使用来自给定灯具的数据运行Django开发服务器(如runserver中所示)。

例如,这个命令:

django-admin testserver mydata.json

...将执行以下步骤:

  1. 创建一个测试数据库,如The test database中所述。
  2. 使用给定灯具的灯具数据填充测试数据库。 (关于夹具的更多信息,请参阅上面的loaddata的文档。)
  3. 运行Django开发服务器(如runserver),指向这个新创建的测试数据库而不是生产数据库。

这在许多方面是有用的:

  • When you’re writing unit tests of how your views act with certain fixture data, you can use testserver to interact with the views in a Web browser, manually.
  • 比方说,你正在开发你的Django应用程序,并有一个你想与之互动的“原始”数据库副本。 你可以把你的数据库转储到一个fixture(使用dumpdata命令,如上所述),然后使用testserver运行你的Web应用程序。 通过这种安排,您可以灵活地以任何方式搞乱您的数据,知道您所做的任何数据更改只能通过测试数据库进行。

请注意,此服务器不会自动检测对您的Python源代码的更改(如runserver所做的那样)。 但是,它确实检测到对模板的更改。

--addrport ADDRPORT

指定默认的127.0.0.1:8000中的不同端口或IP地址和端口。 该值遵循完全相同的格式,并且与runserver命令的参数完全相同。

例子:

要用fixture1fixture2在端口7000上运行测试服务器:

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 T0>, - 无输入 T0> T1> ¶ T2>

禁止所有用户提示。 典型的提示是关于删除现有测试数据库的警告。

由应用程序提供的命令

Some commands are only available when the django.contrib application that implements them has been enabled. 本节将按照其应用程序对其进行分组。

django.contrib.auth

changepassword

django-admin changepassword [&lt; username&gt;]

该命令仅在安装了Django的authentication systemdjango.contrib.auth)时可用。

允许更改用户的密码。 它会提示您为给定用户输入两次新密码。 如果条目相同,则立即成为新密码。 如果您不提供用户,则该命令将尝试更改用户名与当前用户匹配的密码。

- 数据库 数据库

指定要为用户查询的数据库。 默认为default

用法示例:

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser

该命令仅在安装了Django的authentication systemdjango.contrib.auth)时可用。

创建超级用户帐户(拥有所有权限的用户)。 如果您需要创建一个初始的超级用户帐户,或者需要以编程方式为您的站点生成超级用户帐户,这非常有用。

交互式运行时,该命令将提示输入新的超级用户帐户的密码。 当以非交互方式运行时,将不会设置密码,超级用户帐户将无法登录,直到手动设置密码为止。

- 用户名 用户名
- 电子邮件 电子邮件

新帐户的用户名和电子邮件地址可以通过在命令行中使用--username--email参数来提供。 If either of those is not supplied, createsuperuser will prompt for it when running interactively.

- 数据库 数据库

指定将超级用户对象保存到其中的数据库。

如果要自定义数据输入和验证,则可以对管理命令进行子类化并覆盖get_input_data() 有关现有实现和方法参数的详细信息,请参阅源代码。 例如,如果在REQUIRED_FIELDS中有一个ForeignKey,并且希望允许创建一个实例,而不是输入现有实例的主键,那么这会很有用。

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes
Django 1.11新增功能

这个命令只有在安装了Django的contenttypes appdjango.contrib.contenttypes)时才可用。

删除数据库中的陈旧内容类型(从删除的模型)。 任何依赖于被删除的内容类型的对象也将被删除。 在确认可以继续删除之前,将会显示已删除对象的列表。

- 数据库 数据库

指定要使用的数据库。 默认为default

django.contrib.gis

ogrinspect

该命令仅在安装GeoDjangodjango.contrib.gis)时可用。

请参阅GeoDjango文档中的description

django.contrib.sessions

clearsessions

django-admin clearsessions

可以作为cron作业运行,也可以直接清理过期的会话。

django.contrib.sitemaps

ping_google

该命令仅在安装Sitemaps frameworkdjango.contrib.sitemaps)时可用。

请参阅Sitemaps文档中的description

django.contrib.staticfiles

collectstatic

该命令仅在安装static files applicationdjango.contrib.staticfiles)时可用。

请参阅staticfiles文档中的description

findstatic

该命令仅在安装static files applicationdjango.contrib.staticfiles)时可用。

请参阅staticfiles文档中的description

默认选项

尽管一些命令可能允许自己的自定义选项,但是每个命令都可以使用以下选项:

--pythonpath PYTHONPATH

将给定的文件系统路径添加到Python 导入搜索路径中。 If this isn’t provided, django-admin will use the PYTHONPATH environment variable.

这个选项在manage.py中是不必要的,因为它负责为你设置Python路径。

用法示例:

django-admin migrate --pythonpath='/home/djangoprojects/myproject'
--settings 设置

指定要使用的设置模块。 设置模块应该是Python包语法,例如mysite.settings If this isn’t provided, django-admin will use the DJANGO_SETTINGS_MODULE environment variable.

这个选项在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 means no output.
  • 1 means normal output (default).
  • 2 means verbose output.
  • 3 means very verbose output.

用法示例:

django-admin migrate --verbosity 2
- 无色 T0> T1> ¶ T2>

禁用彩色命令输出。 一些命令将其输出格式化为彩色。 例如,错误将以红色打印到控制台,SQL语句将以语法高亮显示。

用法示例:

django-admin runserver --no-color

额外的细节

语法着色

The django-admin / manage.py commands will use pretty color-coded output if your terminal supports ANSI-colored output. 如果您将命令的输出传输到另一个程序,它将不会使用颜色代码。

在Windows下,本机控制台不支持ANSI转义序列,所以默认情况下不会有颜色输出。 But you can install the ANSICON third-party tool, the Django commands will detect its presence and will make use of its services to color output just like on Unix-based platforms.

用于语法高亮的颜色可以自定义。 Django附带三个调色板:

  • dark,适合在黑色背景上显示白色文本的终端。 这是默认的调色板。
  • light, suited to terminals that show black text on a white background.
  • nocolor, which disables syntax highlighting.

您可以通过设置DJANGO_COLORS环境变量来指定要使用的调色板来选择调色板。 例如,要在Unix或OS / X BASH shell下指定light调色板,可以在命令提示符处运行以下命令:

export DJANGO_COLORS="light"

您也可以自定义使用的颜色。 Django指定了许多使用颜色的角色:

  • error - 一个重大错误。
  • notice - A minor error.
  • success - A success.
  • warning - A 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 Not Modified服务器响应。
  • http_redirect - 除304之外的3XX HTTP重定向服务器响应。
  • http_not_found - 404 HTTP Not Found服务器响应。
  • http_bad_request - 除404以外的4XX HTTP Bad Request服务器响应。
  • http_server_error - 5XX HTTP服务器错误响应。
  • migrate_heading - A heading in a migrations management command.
  • 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完成

如果您使用Bash shell,请考虑安装Django发行版中的extras/django_bash_completion中的Django bash完成脚本。 它使标签完成django-adminmanage.py命令,所以你可以,例如...

  • 输入django-admin
  • 按[TAB]查看所有可用的选项。
  • 键入sql,然后选择[TAB],查看名称以sql开头的所有可用选项。

有关如何添加自定义操作,请参阅Writing custom django-admin commands

从代码运行管理命令

django.core.management。call_commandname* 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)

请注意,不带参数的命令选项以TrueFalse的形式作为关键字传递,如上面的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-adminmanage.py时,某些命令选项具有不同的名称。 例如,django-admin createsuperuser - 无输入转换为call_command 'createsuperuser', interactive = False) 要查找用于call_command()的关键字参数名称,请检查传递给parser.add_argument()dest参数的命令源代码。

带有多个选项的命令选项通过一个列表:

management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

call_command()函数的返回值与命令的handle()方法的返回值相同。

输出重定向

请注意,您可以重定向标准输出和错误流,因为所有命令都支持stdoutstderr选项。 例如,你可以写:

with open('/path/to/command_output') as f:
    management.call_command('dumpdata', stdout=f)