Skip to main content

django-adminmanage.py

django-admin 是Django的用于管理任务的命令行实用程序。本文档概述了它可以做的所有事情。

此外,在每个Django项目中自动创建 manage.pymanage.pydjango-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 设置(在 Settings - Control Panel - System - Advanced - Environment... 下)以指向其安装位置。

通常,当在单个Django项目上工作时,使用 manage.py 比使用 django-admin 更容易。如果需要在多个Django设置文件之间切换,请使用 django-adminDJANGO_SETTINGS_MODULE--settings 命令行选项。

本文档中的命令行示例使用 django-admin 来保持一致,但任何示例都可以使用 manage.pypython -m django

New in Django 1.9:

加入 python -m django

用法

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

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

获取运行时帮助

django-admin help

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

运行 django-admin help --commands 以显示所有可用命令的列表。

运行 django-admin help <command> 以显示给定命令的说明及其可用选项的列表。

应用程序名称

许多命令采用“应用程序名称”的列表。 “应用程序名称”是包含模型的软件包的基本名称。例如,如果您的 INSTALLED_APPS 包含字符串 'mysite.blog',则应用程序名称为 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 ...]]

使用 系统检查框架 来检查整个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}
New in Django 1.10.

指定将导致命令以非零状态退出的消息级别。默认为 ERROR

compilemessages

django-admin compilemessages

makemessages 创建的 .po 文件编译为 .mo 文件,以便与内置的gettext支持一起使用。见 国际化和本地化

--locale LOCALE, -l LOCALE

指定要处理的区域设置。如果未提供,则处理所有区域设置。

--exclude EXCLUDE, -x EXCLUDE

指定要从处理中排除的区域设置。如果未提供,则不排除语言环境。

--use-fuzzy, -f

包括模糊翻译成编译文件。

Changed in Django 1.9:

compilemessages 现在匹配 makemessages 的操作,扫描项目树为 .po 文件编译。

用法示例:

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缓存框架

--database DATABASE

指定将在其中创建缓存表的数据库。默认为 default

--dry-run

打印将在没有实际运行的情况下运行的SQL,因此您可以自定义它或使用migrations框架。

Changed in Django 1.9:

添加了 --dry-run 选项。

dbshell

django-admin dbshell

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

  • 对于PostgreSQL,它运行 psql 命令行客户端。

  • 对于MySQL,这运行 mysql 命令行客户端。

  • 对于SQLite,它运行 sqlite3 命令行客户端。

  • 对于Oracle,这将运行 sqlplus 命令行客户端。

此命令假定程序在您的 PATH 上,以便对程序名称(psqlmysqlsqlite3sqlplus)的简单调用将在正确的位置找到程序。没有办法手动指定程序的位置。

--database DATABASE

指定要在其上打开shell的数据库。默认为 default

diffsettings

django-admin diffsettings

显示当前设置文件和Django的默认设置之间的差异。

没有出现在默认值中的设置后面是 "###"。例如,默认设置不定义 ROOT_URLCONF,因此 ROOT_URLCONF 后面是 diffsettings 的输出中的 "###"

--all

显示所有设置,即使他们有Django的默认值。此类设置由 "###" 作为前缀。

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(默认值)时,终端中将显示进度条。

Changed in Django 1.9:

添加终端中的进度条。

flush

django-admin flush

从数据库中删除所有数据并重新执行任何后同步处理程序。已应用迁移的表不会被清除。

如果您希望从空数据库开始并重新运行所有迁移,则应删除并重新创建数据库,然后再运行 migrate

--noinput, --no-input

禁止所有用户提示。

Changed in Django 1.9:

添加了 --no-input 别名。

--database DATABASE

指定要刷新的数据库。默认为 default

inspectdb

django-admin inspectdb [table [table ...]]

内部预测由 NAME 设置指向的数据库中的数据库表,并将Django模型模块(models.py 文件)输出到标准输出。您可以通过将其名称作为参数传递来选择要检查的表。

如果您有要使用Django的旧数据库,请使用此选项。脚本将检查数据库并为其中的每个表创建模型。

正如您所期望的,创建的模型将为表中的每个字段都有一个属性。请注意,inspectdb 在其字段名称输出中有一些特殊情况:

  • 如果 inspectdb 无法将列类型映射到模型字段类型,它将使用 TextField,并将在生成的模型中的字段旁边插入Python注释 'This field type is a guess.'

  • 如果数据库列名是Python保留字(例如 'pass''class''for'),inspectdb 将向属性名称附加 '_field'。例如,如果表具有列 'for',则生成的模型将具有字段 'for_field',其中 db_column 属性被设置为 'for'inspectdb 将在字段旁边插入Python注释 'Field renamed because it was a Python reserved word.'

此功能意味着一个快捷方式,而不是确定的模型生成。运行它之后,您将需要自己查看生成的模型以进行自定义。特别是,您需要重新排列模型的顺序,以便引用其他模型的模型正确排序。

主键自动自动检查PostgreSQL,MySQL和SQLite,在这种情况下Django放在 primary_key=True 在需要的地方。

inspectdb 与PostgreSQL,MySQL和SQLite。外键检测只适用于PostgreSQL和某些类型的MySQL表。

在模型字段上指定 default 时,Django不会创建数据库默认值。类似地,数据库默认值不会转换为模型字段默认值,或者 inspectdb 以任何方式检测。

默认情况下,inspectdb 创建非托管模型。也就是说,模型的 Meta 类中的 managed = False 告诉Django不要管理每个表的创建,修改和删除。如果你想让Django管理表的生命周期,你需要将 managed 选项改为 True (或者简单地删除它,因为 True 是它的默认值)。

New in Django 1.10:

增加了对 table 参数的支持,以选择应检查哪些表。

--database DATABASE

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

loaddata

django-admin loaddata fixture [fixture ...]

搜索并将命名夹具的内容加载到数据库中。

--database DATABASE

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

--ignorenonexistent, -i

忽略自固件最初生成后可能已删除的字段和模型。

--app APP_LABEL

指定单个应用程序来查找fixtures而不是查看所有应用程序。

什么是“夹具”?

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

Django将在三个位置搜索灯具:

  1. 在每个已安装应用程序的 fixtures 目录中

  2. FIXTURE_DIRS 设置中命名的任何目录中

  3. 在灯具命名的文字路径

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

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

django-admin loaddata mydata.json

将只加载名为 mydata 的JSON夹具。夹具扩展名必须对应于 串行器 的注册名称(例如,jsonxml)。

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

django-admin loaddata mydata

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

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

django-admin loaddata foo/bar/mydata.json

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

当夹具文件被处理时,数据被保存到数据库。模型定义的 save() 方法不被调用,任何 pre_savepost_save 信号将用 raw=True 调用,因为实例仅包含模型本地的属性。例如,您可以禁用处理程序访问相关字段,这些字段在夹具加载期间不存在,否则会引发异常:

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 中的任一个。使用压缩压缩归档文件中包含的第一个文件。

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

MySQL与MyISAM和fixtures

MySQL的MyISAM存储引擎不支持事务或约束,因此如果您使用MyISAM,您将不会获得夹具数据的验证,或者如果找到多个事务文件,则回滚。

数据库特定夹具

如果您在多数据库设置中,您可能需要将夹具数据加载到一个数据库,但不加载到另一个数据库。在这种情况下,您可以将数据库标识符添加到灯具的名称中。

例如,如果您的 DATABASES 设置定义了一个“主”数据库,则将夹具命名为 mydata.master.jsonmydata.master.json.gz,并且仅当您指定要将数据加载到 master 数据库中时,才会加载夹具。

makemessages

django-admin makemessages

运行在当前目录的整个源树上,并拉出所有标记为要翻译的字符串。它在conf/locale(在Django树中)或locale(对于项目和应用程序)目录中创建(或更新)消息文件。更改消息文件后,您需要使用 compilemessages 编译它们以与内置的gettext支持一起使用。有关详细信息,请参阅 i18n文档

--all, -a

更新所有可用语言的消息文件。

--extension EXTENSIONS, -e EXTENSIONS

指定要检查的文件扩展名的列表(默认值:htmltxtpyjs,如果 --domainjs)。

用法示例:

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=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
--domain DOMAIN, -d DOMAIN

指定消息文件的域。支持的选项有:

  • django 用于所有 *.py*.html*.txt 文件(默认)

  • djangojs 用于 *.js 文件

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

用法示例:

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 ”注释行。使用此选项使技术熟练的翻译人员更难理解每个消息的上下文。

--keep-pot

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

参见

有关如何自定义 makemessages 传递给 xgettext 的关键字的说明,请参阅 自定义 makemessages 命令

makemigrations

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

根据检测到的模型创建新的迁移。迁移,他们与应用程序的关系和更多在 the migrations documentation 深入讨论。

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

--noinput, --no-input

禁止所有用户提示。如果无法自动解决抑制的提示,则命令将退出,错误代码为3。

Changed in Django 1.9:

添加了 --no-input 别名。

--empty

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

--dry-run

显示在不实际将任何迁移文件写入磁盘的情况下将执行的迁移。与 --verbosity 3 一起使用此选项还将显示将要写入的完整迁移文件。

--merge

允许修复迁移冲突。

--name NAME, -n NAME

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

--exit, -e

1.10 版后已移除: 请改用 --check 选项。

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

--check
New in Django 1.10.

在检测到没有迁移的模型更改时,使 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
New in Django 1.9.

允许在没有迁移的情况下为应用创建表。虽然不建议这样做,但迁移框架有时在包含数百个模型的大型项目中太慢。

--noinput, --no-input

禁止所有用户提示。示例提示要求删除过时的内容类型。

Changed in Django 1.9:

添加了 --no-input 别名。

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 应用程序(在新项目中为默认),则 runserver 命令将被自己的 runserver 命令覆盖。

如果先前未执行 migrate,则存储迁移历史的表在首次运行 runserver 时创建。

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

Changed in Django 1.10:

在旧版本中,日志消息写入 sys.stderr,而不是通过Python日志记录处理。

--noreload

禁用自动重装器。这意味着当服务器运行时,您所做的任何Python代码更改将在 not 生效,如果特定的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

端口7000在IPv6地址 ::1 上:

django-admin runserver -6 7000

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

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

端口8000在主机 localhost 的IPv4地址:

django-admin runserver localhost:8000

端口8000在主机 localhost 的IPv6地址:

django-admin runserver -6 localhost:8000

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

默认情况下,开发服务器不会为您的网站提供任何静态文件(例如CSS文件,图像,MEDIA_URL 下的内容等)。如果要配置Django以提供静态媒体,请阅读 管理静态文件(例如图片,JavaScript,CSS)

sendtestemail

django-admin sendtestemail [email [email ...]]
New in Django 1.9.

向指定的收件人发送测试电子邮件(以确认通过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将使用 IPythonbpython (如果已安装)。如果两者都安装,请指定您想要的那样:

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
New in Django 1.10.

让你传递一个命令作为一个字符串来执行它作为Django,像这样:

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

showmigrations

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

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

--list, -l

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

还列出了没有迁移的应用程序,但在其下面打印了 (no migrations)

这是默认的输出格式。

--plan, -p

显示Django将遵循的迁移计划以应用迁移。任何提供的应用标签都会被忽略,因为计划可能超出这些应用。与 --list 一样,应用迁移由 [X] 标记。对于2和以上的 --verbosity,还将显示迁移的所有依赖性。

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

Changed in Django 1.9:

为了提高整个SQL输出的可读性,为每个迁移操作生成的SQL代码前面是操作的描述。

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)迁移到较少的迁移(如果可能)。由此造成的被挤压的迁移可以安全地与未被挖掘的迁移。有关更多信息,请阅读 挤压迁移

New in Django 1.9.

当给出 start_migration_name 时,Django将仅包括从迁移开始并包括此迁移的迁移。这有助于减轻 RunPythondjango.db.migrations.operations.RunSQL 迁移操作的压缩限制。

--no-optimize

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

--noinput, --no-input

禁止所有用户提示。

Changed in Django 1.9:

添加了 --no-input 别名。

startapp

django-admin startapp name [directory]

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

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

如果提供了可选目标,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(httphttpsftp)以压缩存档与应用程序模板文件,下载和提取它们在飞行。

例如,利用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 - 应用程序名称为camel case格式

  • docs_version - 文档的版本:'dev''1.x'

New in Django 1.9:

加入 camel_case_app_name

警告

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

要解决此问题,您可以使用 templatetag 模板标记“转义”模板语法的各个部分。

此外,为了允许包含Django模板语言语法的Python模板文件,同时还防止包装系统尝试字节编译无效的 *.py 文件,以 .py-tpl 结尾的模板文件将重命名为 .py

Changed in Django 1.9.2:

添加了 .py-tpl 重命名为 .py

startproject

django-admin startproject name [directory]

在当前目录或给定目标中为给定项目名称创建Django项目目录结构。

默认情况下,新目录包含 manage.py 和项目包(包含 settings.py 和其他文件)。有关详细信息,请参阅 template source

如果只给出项目名称,则项目目录和项目包都将命名为 <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'

请参阅 startapp 提到的 渲染警告

test

django-admin test [test_label [test_label ...]]

对所有已安装的应用程序运行测试。有关详细信息,请参阅 在Django中测试

--failfast

停止运行测试,并在测试失败后立即报告失败。

--testrunner TESTRUNNER

控制用于执行测试的测试运行器类。此值将覆盖由 TEST_RUNNER 设置提供的值。

--liveserver LIVESERVER

覆盖活动服务器(与 LiveServerTestCase 一起使用)将运行的默认地址。默认值为 localhost:8081-8179

Changed in Django 1.9:

在早期版本中,默认值为 localhost:8081

--noinput, --no-input

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

Changed in Django 1.9:

添加了 --no-input 别名。

测试运行程序选项

test 命令代表指定的 --testrunner 接收选项。这些是默认测试运行器的选项:DiscoverRunner

--keepdb, -k

在测试运行之间保留测试数据库。这具有跳过创建和销毁操作的优点,这可以大大减少运行测试的时间,特别是在大型测试套件中。如果测试数据库不存在,它将在第一次运行时创建,然后为每个后续运行保留。任何未应用的迁移也将在运行测试套件之前应用于测试数据库。

--reverse, -r

以相反的执行顺序排序测试用例。这可能有助于调试未正确隔离的测试的副作用。使用此选项时将保留 按测试类分组

--debug-sql, -d

为失败的测试启用 SQL日志。如果 --verbosity2,则也会输出通过测试中的查询。

--parallel [N]
New in Django 1.9.

在单独的并行进程中运行测试。由于现代处理器具有多个内核,因此可以更快地运行测试。

默认情况下,--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可能无法显示异常跟踪。这可能使调试困难。如果遇到此问题,请运行受影响的测试而不并行化以查看故障的追溯。

这是已知的限制。它起源于需要序列化对象以便在进程之间交换它们。有关详细信息,请参阅 What can be pickled and unpickled?

--tag TAGS
New in Django 1.10.

仅运行测试 标记有指定的标签。可以多次指定并与 test --exclude-tag 结合使用。

--exclude-tag EXCLUDE_TAGS
New in Django 1.10.

不包括测试 标记有指定的标签。可以多次指定并与 test --tag 结合使用。

testserver

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

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

例如,此命令:

django-admin testserver mydata.json

...将执行以下步骤:

  1. 创建测试数据库,如 测试数据库 中所述。

  2. 使用来自给定夹具的夹具数据填充测试数据库。 (有关夹具的更多信息,请参阅上述 loaddata 的文档。)

  3. 运行Django开发服务器(如在 runserver 中),指向此新创建的测试数据库,而不是生产数据库。

这在许多方面是有用的:

  • 当您在编写 单元测试 时,您的视图如何使用某些夹具数据,您可以使用 testserver 在Web浏览器中手动与视图交互。

  • 假设您正在开发您的Django应用程序,并且拥有一个要与之交互的数据库的“原始”副本。您可以将数据库转储到夹具(使用 dumpdata 命令,如上所述),然后使用 testserver 运行带有该数据的Web应用程序。通过这种安排,您可以以任何方式灵活地混淆数据,因为知道您正在进行的任何数据更改只会发送到测试数据库。

请注意,此服务器会使 not 自动检测对您的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

(上面的语句是等价的,我们包括它们两者,以证明选项在fixture参数之前或之后是无关紧要的。)

使用 test 夹具在1.2.3.4:7000上运行:

django-admin testserver --addrport 1.2.3.4:7000 test
--noinput, --no-input

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

Changed in Django 1.9:

添加了 --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()。有关现有实现和方法参数的详细信息,请参阅源代码。例如,如果您在 REQUIRED_FIELDS 中具有 ForeignKey,并且希望允许创建实例而不是输入现有实例的主键,那么这将非常有用。

django.contrib.gis

ogrinspect

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

请参阅其在GeoDjango文档中的 description

django.contrib.sessions

clearsessions

django-admin clearsessions

可以作为cron作业运行或直接清除过期的会话。

django.contrib.sitemaps

ping_google

此命令仅在安装了 Sitemaps框架django.contrib.sitemaps)时可用。

请参阅Sitemap说明文件中的 description

django.contrib.staticfiles

collectstatic

此命令仅在安装了 静态文件应用程序django.contrib.staticfiles)时可用。

请参阅 静态文件 文档中的 description

findstatic

此命令仅在安装了 静态文件应用程序django.contrib.staticfiles)时可用。

请参阅 静态文件 文档中的 description

默认选项

虽然某些命令可能允许自己的自定义选项,但每个命令允许以下选项:

--pythonpath PYTHONPATH

将给定的文件系统路径添加到Python import search path。如果没有提供,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 升起时,显示一个完整的堆栈跟踪。默认情况下,django-admin 将在发生 CommandError 时显示一个简单的错误消息,并显示任何其他异常的完整堆栈跟踪。

用法示例:

django-admin migrate --traceback
--verbosity {0,1,2,3}, --v {0,1,2,3}

指定命令应打印到控制台的通知和调试信息量。

  • 0 表示无输出。

  • 1 表示正常输出(默认)。

  • 2 意味着详细输出。

  • 3 表示 very 详细输出。

用法示例:

django-admin migrate --verbosity 2
--no-color

禁用彩色命令输出。一些命令将其输出格式化为彩色化。例如,错误将以红色打印到控制台,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 - A 304 HTTP未修改服务器响应。

  • http_redirect - 3XX HTTP除304之外的重定向服务器响应。

  • http_not_found - 404 HTTP未找到服务器响应。

  • http_bad_request - 4XX HTTP请求服务器响应404以外的请求。

  • http_server_error - 5XX HTTP Server错误响应。

  • migrate_heading - 迁移管理命令中的标题。

  • migrate_label - 迁移名称。

Changed in Django 1.9:

加入 success

可以从以下列表中为这些角色中的每个角色分配特定的前景和背景颜色:

  • 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"

将指定使用所有的颜色在浅色调色板,except 的颜色的错误和通知,将被重写的指定。

Bash完成

如果使用Bash shell,请考虑安装Django bash完成脚本,它位于Django发行版中的 extras/django_bash_completion 中。它启用 django-adminmanage.py 命令的制表符完成,因此您可以,例如...

  • 类型 django-admin

  • 按[TAB]查看所有可用选项。

  • 键入 sql,然后单击[TAB],查看其名称以 sql 开头的所有可用选项。

有关如何添加自定义操作,请参阅 编写自定义 django-admin 命令

从代码运行管理命令

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)

请注意,不带参数的命令选项将作为关键字传递给 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)

传递多个选项的命令选项传递列表:

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

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

Changed in Django 1.10:

call_command() 现在返回从 command.handle() 方法接收的值。它现在也接受一个命令对象作为第一个参数。

输出重定向

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

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