新博客链接:http://www.angeszhu.cn/2020/06/08/django-admin/,欢迎大家关注评论。

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每个已安装的应用程序, /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> :将数据库架构置于应用命名迁移的状态,但不应用同一应用程序中的后续迁移。如果您之前已迁移过指定的迁移,则可能涉及取消应用迁移。使用该名称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

版权声明:本文为AngesZhu原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/AngesZhu/p/13067250.html