django-adminおよびmanage.py

django-adminは、管理タスク用のDjangoのコマンドラインユーティリティです。このドキュメントでは、実行できるすべての概要を説明します。

さらに、manage.pyは各Djangoプロジェクトで自動的に作成されます。 django-adminと同じことを行いますが、プロジェクトのsettings.pyファイルを指すように、 DJANGO_SETTINGS_MODULE 環境変数も設定します。

pipを介してDjangoをインストールした場合は、django-adminスクリプトがシステムパス上にあるはずです。パスにない場合は、仮想環境がアクティブになっていることを確認してください。

一般に、単一のDjangoプロジェクトで作業する場合は、django-adminよりもmanage.pyを使用する方が簡単です。複数のDjango設定ファイルを切り替える必要がある場合は、django-adminと DJANGO_SETTINGS_MODULE または--settingsコマンドラインオプションを使用します。

このドキュメント全体のコマンドラインの例では、一貫性を保つためにdjango-adminを使用していますが、どの例でもmanage.pyまたはpython -m djangoを使用できます。

使用法

commandは、このドキュメントに記載されているコマンドの1つである必要があります。オプションのoptionsは、指定されたコマンドで使用可能なオプションの0個以上である必要があります。

ランタイムヘルプの取得

django-admin helpを実行して、使用情報と各アプリケーションが提供するコマンドのリストを表示します。

django-admin help --commandsを実行して、使用可能なすべてのコマンドのリストを表示します。

django-admin help <command>を実行して、指定されたコマンドの説明と使用可能なオプションのリストを表示します。

アプリ名

多くのコマンドは「アプリ名」のリストを取ります。「アプリ名」は、モデルを含むパッケージのベース名です。たとえば、：setting： `INSTALLED_APPS` に文字列'mysite.blog'が含まれている場合、アプリ名はblogになります。

バージョンの決定

django-admin versionを実行して、現在のDjangoバージョンを表示します。

出力は、 PEP 440 で説明されているスキーマに従います。

4.dev17026
4a1
4

デバッグ出力の表示

--verbosityがサポートされている場合は、django-adminがコンソールに出力する通知およびデバッグ情報の量を指定します。

使用可能なコマンド

check

システムチェックフレームワークを使用して、Djangoプロジェクト全体に一般的な問題がないか検査します。

デフォルトでは、すべてのアプリがチェックされます。引数としてアプリラベルのリストを提供することで、アプリのサブセットを確認できます。

django-admin check auth admin myapp

システムチェックフレームワークは、タグで分類されたさまざまなタイプのチェックを実行します。これらのタグを使用して、実行されるチェックを特定のカテゴリのチェックのみに制限できます。たとえば、モデルと互換性チェックのみを実行するには、次のコマンドを実行します。

django-admin check --tag models --tag compatibility

バージョン3.1の新機能。

データベースアクセスを必要とするチェックを実行するデータベースを指定します。

django-admin check --database default --database other

デフォルトでは、これらのチェックは実行されません。

使用可能なすべてのタグを一覧表示します。

展開設定にのみ関連するいくつかの追加チェックをアクティブにします。

このオプションはローカル開発環境で使用できますが、ローカル開発設定モジュールには多くの本番設定が含まれていない可能性があるため、checkコマンドを別の設定モジュールに向けることをお勧めします。 DJANGO_SETTINGS_MODULE 環境変数、または--settingsオプションを渡すことによって：

django-admin check --deploy --settings=production_settings

または、本番デプロイメントまたはステージングデプロイメントで直接実行して、正しい設定が使用されていることを確認することもできます（--settingsを省略）。統合テストスイートの一部にすることもできます。

コマンドをゼロ以外のステータスで終了させるメッセージレベルを指定します。デフォルトはERRORです。

compilemessages

：djadmin： `makemessages` によって作成された.poファイルを、組み込みのgettextサポートで使用するために.moファイルにコンパイルします。国際化とローカリゼーションを参照してください。

処理するロケールを指定します。指定しない場合、すべてのロケールが処理されます。

処理から除外するロケールを指定します。指定しない場合、ロケールは除外されません。

ファジー翻訳をコンパイル済みファイルに含めます。

使用例：

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

指定されたglobスタイルのパターンに一致するディレクトリを無視します。さらに無視するには、複数回使用します。

使用例：

django-admin compilemessages --ignore=cache --ignore=outdated/*/locale

createcachetable

設定ファイルの情報を使用して、データベースキャッシュバックエンドで使用するキャッシュテーブルを作成します。詳細については、 Djangoのキャッシュフレームワークを参照してください。

キャッシュテーブルが作成されるデータベースを指定します。デフォルトはdefaultです。

実際に実行せずに実行されるSQLを出力するため、SQLをカスタマイズしたり、移行フレームワークを使用したりできます。

dbshell

で指定されたデータベースエンジンのコマンドラインクライアントを実行します：setting： `ENGINE ` で指定された接続パラメータを使用した設定：setting： `USER` 、：setting： `PASSWORD` 、などの設定。

PostgreSQLの場合、これはpsqlコマンドラインクライアントを実行します。
MySQLの場合、これはmysqlコマンドラインクライアントを実行します。
SQLiteの場合、これはsqlite3コマンドラインクライアントを実行します。
Oracleの場合、これはsqlplusコマンドラインクライアントを実行します。

このコマンドは、プログラムがPATHにあることを前提としているため、プログラム名（psql、mysql、sqlite3、sqlplus ）適切な場所にプログラムが見つかります。プログラムの場所を手動で指定する方法はありません。

シェルを開くデータベースを指定します。デフォルトはdefaultです。

バージョン3.1の新機能。

--除算器に続く引数はすべて、基になるコマンドラインクライアントに渡されます。たとえば、PostgreSQLでは、psqlコマンドの-cフラグを使用して、生のSQLクエリを直接実行できます。

MySQL / MariaDBでは、mysqlコマンドの-eフラグを使用してこれを行うことができます。

ノート

：setting： `DATABASES` のデータベース構成の：setting：` OPTIONS` 部分で設定されたすべてのオプションが、コマンドラインクライアントに渡されるわけではないことに注意してください。 'isolation_level'。

diffsettings

現在の設定ファイルとDjangoのデフォルト設定（または--defaultで指定された別の設定ファイル）の違いを表示します。

デフォルトに表示されない設定の後には"###"が続きます。たとえば、デフォルト設定では：setting： `ROOT_URLCONF` が定義されていないため、：setting：` ROOT_URLCONF` の後に"###"が続きます。 X159X] 。

Djangoのデフォルト値がある場合でも、すべての設定を表示します。このような設定には、"###"というプレフィックスが付いています。

現在の設定を比較するための設定モジュール。 Djangoのデフォルト設定と比較するには、空のままにします。

出力形式を指定します。使用可能な値は、hashおよびunifiedです。 hashは、上記の出力を表示するデフォルトのモードです。 unifiedは、diff -uと同様の出力を表示します。デフォルト設定の前にはマイナス記号が付いており、その後に変更された設定の前にプラス記号が付いています。

dumpdata

指定されたアプリケーションに関連付けられたデータベース内のすべてのデータを標準出力に出力します。

アプリケーション名が指定されていない場合、インストールされているすべてのアプリケーションがダンプされます。

dumpdataの出力は、：djadmin： `loaddata` の入力として使用できます。

dumpdataは、ダンプするレコードを選択するためにモデルのデフォルトマネージャーを使用することに注意してください。カスタムマネージャーをデフォルトのマネージャーとして使用していて、使用可能なレコードの一部をフィルター処理する場合、すべてのオブジェクトがダンプされるわけではありません。

Djangoのベースマネージャーを使用し、カスタムマネージャーによってフィルタリングまたは変更される可能性のあるレコードをダンプします。

出力のシリアル化形式を指定します。デフォルトはJSONです。サポートされている形式は、シリアル化形式にリストされています。

出力で使用するインデントスペースの数を指定します。デフォルトはNoneで、すべてのデータを1行で表示します。

特定のアプリケーションまたはモデル（app_label.ModelNameの形式で指定）がダンプされないようにします。モデル名を指定すると、アプリケーション全体ではなく、そのモデルのみが除外されます。アプリケーション名とモデル名を混在させることもできます。

複数のアプリケーションを除外する場合は、--excludeを複数回渡します。

django-admin dumpdata --exclude=auth --exclude=contenttypes

データのダンプ元のデータベースを指定します。デフォルトはdefaultです。

natural_key()モデルメソッドを使用して、メソッドを定義するタイプのオブジェクトへの外部キーおよび多対多の関係をシリアル化します。 contrib.auth Permissionオブジェクトまたはcontrib.contenttypes ContentTypeオブジェクトをダンプする場合は、おそらくこのフラグを使用する必要があります。このオプションと次のオプションの詳細については、自然キーのドキュメントを参照してください。

このオブジェクトのシリアル化されたデータの主キーは、逆シリアル化中に計算できるため、省略します。

主キーのコンマ区切りリストで指定されたオブジェクトのみを出力します。これは、1つのモデルをダンプする場合にのみ使用できます。デフォルトでは、モデルのすべてのレコードが出力されます。

シリアル化されたデータを書き込むファイルを指定します。デフォルトでは、データは標準出力に送られます。

このオプションが設定されていて、--verbosityが0（デフォルト）より大きい場合、端末にプログレスバーが表示されます。

備品の圧縮

バージョン3.2の新機能。

出力ファイルは、ファイル名を対応する拡張子で終了することにより、bz2、gz、lzma、またはxz形式のいずれかで圧縮できます。たとえば、データを圧縮されたJSONファイルとして出力するには、次のようにします。

django-admin dumpdata -o mydata.json.gz

flush

データベースからすべてのデータを削除し、同期後のハンドラーを再実行します。移行が適用されたテーブルはクリアされません。

空のデータベースから開始してすべての移行を再実行する場合は、データベースを削除して再作成してから、代わりに：djadmin： `migrate` を実行する必要があります。

すべてのユーザープロンプトを抑制します。

フラッシュするデータベースを指定します。デフォルトはdefaultです。

inspectdb

：setting： `NAME` 設定が指すデータベース内のデータベーステーブルをイントロスペクトし、Djangoモデルモジュール（models.pyファイル）を標準出力に出力します。

名前を引数として渡すことにより、検査するテーブルまたはビューを選択できます。引数が指定されていない場合、--include-viewsオプションが使用されている場合にのみ、ビューのモデルが作成されます。 --include-partitionsオプションが使用されている場合、パーティションテーブルのモデルはPostgreSQLで作成されます。

Djangoを使用するレガシーデータベースがある場合は、これを使用します。スクリプトはデータベースを検査し、データベース内の各テーブルのモデルを作成します。

ご想像のとおり、作成されたモデルには、テーブル内のすべてのフィールドの属性があります。 inspectdbのフィールド名の出力には、いくつかの特殊なケースがあることに注意してください。

inspectdbが列の型をモデルフィールド型にマップできない場合、TextFieldを使用し、生成されたモデルのフィールドの横にPythonコメント'This field type is a guess.'を挿入します。認識されるフィールドは、：setting： `INSTALLED_APPS` にリストされているアプリによって異なる場合があります。たとえば、 django.contrib.postgres は、いくつかのPostgreSQL固有のフィールドタイプの認識を追加します。
データベースの列名がPythonの予約語（'pass'、'class'、'for'など）の場合、inspectdbは'_field'をに追加します属性名。たとえば、テーブルに列'for'がある場合、生成されたモデルにはフィールド'for_field'があり、db_column属性は'for'に設定されます。 inspectdbは、フィールドの横にPythonコメント'Field renamed because it was a Python reserved word.'を挿入します。

この機能は、最終的なモデル生成ではなく、ショートカットとして意図されています。実行したら、生成されたモデルを自分で調べてカスタマイズする必要があります。特に、他のモデルを参照するモデルが正しく順序付けられるように、モデルの順序を並べ替える必要があります。

モデルフィールドで default が指定されている場合、Djangoはデータベースのデフォルトを作成しません。同様に、データベースのデフォルトは、モデルフィールドのデフォルトに変換されたり、inspectdbによって検出されたりすることはありません。

デフォルトでは、inspectdbはアンマネージモデルを作成します。つまり、モデルのMetaクラスのmanaged = Falseは、各テーブルの作成、変更、および削除を管理しないようにDjangoに指示します。 Djangoにテーブルのライフサイクルの管理を許可する場合は、 managed オプションをTrueに変更する必要があります（またはTrueがデフォルト値であるため削除します））。

データベース固有の注意事項

オラクル

--include-viewsが使用されている場合、モデルはマテリアライズド・ビュー用に作成されます。

PostgreSQL

モデルは外部テーブル用に作成されます。
--include-viewsが使用されている場合、モデルはマテリアライズド・ビュー用に作成されます。
--include-partitionsを使用すると、パーティションテーブルのモデルが作成されます。

イントロスペクトするデータベースを指定します。デフォルトはdefaultです。

このオプションを指定すると、パーティションのモデルも作成されます。

PostgreSQLのサポートのみが実装されています。

このオプションを指定すると、データベースビューのモデルも作成されます。

loaddata

指定されたフィクスチャのコンテンツを検索してデータベースにロードします。

データがロードされるデータベースを指定します。デフォルトはdefaultです。

フィクスチャが最初に生成されてから削除された可能性のあるフィールドとモデルを無視します。

すべてのアプリを検索するのではなく、フィクスチャを検索する単一のアプリを指定します。

stdin から読み取ったフィクスチャのシリアル化形式（jsonまたはxmlなど）を指定します。

特定のアプリケーションおよび/またはモデルからのフィクスチャのロードを除外します（app_labelまたはapp_label.ModelNameの形式で）。このオプションを複数回使用して、複数のアプリまたはモデルを除外します。

「フィクスチャ」とは何ですか？

フィクスチャは、データベースのシリアル化されたコンテンツを含むファイルのコレクションです。各フィクスチャには一意の名前があり、フィクスチャを構成するファイルは、複数のアプリケーションの複数のディレクトリに分散できます。

Djangoは、次の3つの場所でフィクスチャを検索します。

インストールされているすべてのアプリケーションのfixturesディレクトリ
：setting： `FIXTURE_DIRS` 設定で指定された任意のディレクトリ
フィクスチャによって指定されたリテラルパス内

Djangoは、これらの場所で見つかった、提供されたフィクスチャー名と一致するすべてのフィクスチャーをロードします。

指定されたフィクスチャにファイル拡張子がある場合、そのタイプのフィクスチャのみがロードされます。例えば：

django-admin loaddata mydata.json

mydataと呼ばれるJSONフィクスチャのみをロードします。フィクスチャ拡張子は、シリアライザの登録名に対応している必要があります（例：jsonまたはxml）。

拡張機能を省略すると、Djangoは利用可能なすべてのフィクスチャタイプで一致するフィクスチャを検索します。例えば：

django-admin loaddata mydata

mydataと呼ばれるフィクスチャタイプのフィクスチャを探します。フィクスチャディレクトリにmydata.jsonが含まれている場合、そのフィクスチャはJSONフィクスチャとしてロードされます。

名前が付けられたフィクスチャには、ディレクトリコンポーネントを含めることができます。これらのディレクトリは検索パスに含まれます。例えば：

django-admin loaddata foo/bar/mydata.json

インストールされている各アプリケーションの<app_label>/fixtures/foo/bar/mydata.json、：setting： `FIXTURE_DIRS` の各ディレクトリの<dirname>/foo/bar/mydata.json、およびリテラルパスfoo/bar/mydata.jsonを検索します。

フィクスチャファイルが処理されると、データはそのままデータベースに保存されます。モデル定義の save（）メソッドは呼び出されず、インスタンスには属性のみが含まれるため、 pre_save または post_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の間だけでなく、フィクスチャが逆シリアル化されるたびに信号を無効にすることに注意してください。

フィクスチャファイルが処理される順序は定義されていないことに注意してください。ただし、すべてのフィクスチャデータは単一のトランザクションとしてインストールされるため、あるフィクスチャのデータは別のフィクスチャのデータを参照できます。データベースバックエンドが行レベルの制約をサポートしている場合、これらの制約はトランザクションの最後にチェックされます。

：djadmin： `dumpdata` コマンドを使用して、loaddataの入力を生成できます。

圧縮された器具

フィクスチャは、zip、gz、bz2、lzma、またはxz形式で圧縮できます。例えば：

django-admin loaddata mydata.json

mydata.json、mydata.json.zip、mydata.json.gz、mydata.json.bz2、mydata.json.lzma、またはmydata.json.xzのいずれかを検索します。圧縮アーカイブに含まれる最初のファイルが使用されます。

同じ名前でフィクスチャタイプが異なる2つのフィクスチャが検出された場合（たとえば、mydata.jsonとmydata.xml.gzが同じフィクスチャディレクトリで見つかった場合）、フィクスチャのインストールは中止され、 loaddataの呼び出しでインストールされたデータはデータベースから削除されます。

MyISAMとフィクスチャを備えたMySQL

MySQLのMyISAMストレージエンジンはトランザクションまたは制約をサポートしていないため、MyISAMを使用する場合、フィクスチャデータの検証、または複数のトランザクションファイルが見つかった場合のロールバックは取得されません。

バージョン3.2で変更： XZアーカイブ（.xz）およびLZMAアーカイブ（.lzma）のサポートが追加されました。

データベース固有のフィクスチャ

マルチデータベース設定を使用している場合は、あるデータベースにロードしたいが別のデータベースにはロードしたくないフィクスチャデータがある可能性があります。この状況では、フィクスチャの名前にデータベース識別子を追加できます。

たとえば、：setting： `DATABASES` 設定に「master」データベースが定義されている場合、フィクスチャにmydata.master.jsonまたはmydata.master.json.gzという名前を付けると、フィクスチャは次の場合にのみロードされます。 masterデータベースにデータをロードすることを指定します。

stdinからフィクスチャをロードしています

sys.stdinからの入力をロードするために、フィクスチャー名としてダッシュを使用できます。例えば：

django-admin loaddata --format=json -

stdinから読み取る場合、入力のシリアル化形式を指定するには、--formatオプションが必要です（例：jsonまたはxml）。）。

stdinからのロードは、標準の入力および出力リダイレクトで役立ちます。例えば：

django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -

makemessages

現在のディレクトリのソースツリー全体を実行し、翻訳用にマークされたすべての文字列を引き出します。 conf / locale（Djangoツリー内）またはlocale（プロジェクトおよびアプリケーション用）ディレクトリにメッセージファイルを作成（または更新）します。メッセージファイルに変更を加えた後、組み込みのgettextサポートで使用するために、：djadmin： `compilemessages` でそれらをコンパイルする必要があります。詳細については、 i18nドキュメントを参照してください。

このコマンドには、構成済みの設定は必要ありません。ただし、設定が構成されていない場合、コマンドは：setting： `MEDIA_ROOT` および：setting：` STATIC_ROOT` ディレクトリを無視したり、：setting：を含めたりすることはできません。 `LOCALE_PATHS` 。

使用可能なすべての言語のメッセージファイルを更新します。

調べるファイル拡張子のリストを指定します（デフォルト：--domainが [の場合、html、txt、py、またはjs X122X]）。

使用例：

django-admin makemessages --locale=de --extension xhtml

複数の拡張子をカンマで区切るか、-eまたは--extensionを複数回使用します。

django-admin makemessages --locale=de --extension=html,txt --extension xml

処理するロケールを指定します。

処理から除外するロケールを指定します。指定しない場合、ロケールは除外されません。

使用例：

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

メッセージファイルのドメインを指定します。サポートされているオプションは次のとおりです。

すべての*.py、*.html、および*.txtファイルのdjango（デフォルト）
*.jsファイルの場合はdjangojs

新しい翻訳文字列を探すときは、ディレクトリへのシンボリックリンクをたどります。

使用例：

django-admin makemessages --locale=de --symlinks

指定されたglobスタイルのパターンに一致するファイルまたはディレクトリを無視します。さらに無視するには、複数回使用します。

これらのパターンはデフォルトで使用されます：'CVS'、'.*'、'*~'、'*.pyc'。

使用例：

django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

--ignoreのデフォルト値を無効にします。

言語ファイルで長いメッセージ行を複数行に分割することを無効にします。

言語ファイルへの「#: filename:line」コメント行の書き込みを抑制します。このオプションを使用すると、技術的に熟練した翻訳者が各メッセージのコンテキストを理解するのが難しくなります。

言語ファイルの#: filename:lineコメント行を制御します。オプションが次の場合：

full（指定されていない場合のデフォルト）：行にはファイル名と行番号の両方が含まれます。
file：行番号は省略されています。
never：線が抑制されます（--no-locationと同じ）。

gettext 0.19以降が必要です。

.poファイルを作成する前に生成された一時的な.potファイルが削除されないようにします。これは、最終的な言語ファイルの作成を妨げる可能性のあるエラーのデバッグに役立ちます。

も参照してください

：djadmin： `makemessages` がxgettextに渡すキーワードをカスタマイズする方法については、 makemessagesコマンドのカスタマイズを参照してください。

makemigrations

モデルに対して検出された変更に基づいて、新しい移行を作成します。移行、アプリとの関係などについては、移行ドキュメントで詳しく説明されています。

1つ以上のアプリ名を引数として指定すると、指定されたアプリと必要な依存関係（ForeignKeyの反対側のテーブルなど）に作成される移行が制限されます。

migrationsディレクトリがないアプリに移行を追加するには、アプリのapp_labelでmakemigrationsを実行します。

すべてのユーザープロンプトを抑制します。抑制されたプロンプトを自動的に解決できない場合、コマンドはエラーコード3で終了します。

手動編集のために、指定されたアプリの空の移行を出力します。これは上級ユーザー向けであり、移行形式、移行操作、および移行間の依存関係に精通していない限り、使用しないでください。

移行ファイルを実際にディスクに書き込まずに行われる移行を示します。このオプションを--verbosity 3と一緒に使用すると、書き込まれる完全な移行ファイルも表示されます。

移行の競合の修正を有効にします。

生成された名前を使用する代わりに、生成された移行に名前を付けることができます。名前は有効なPython 識別子である必要があります。

Djangoのバージョンとタイムスタンプヘッダーなしで移行ファイルを生成します。

移行なしのモデル変更が検出された場合、makemigrationsをゼロ以外のステータスで終了させます。

バージョン3.2で変更：アクティブなデータベース接続なしでmakemigrationsを呼び出すためのサポートが追加されました。その場合、一貫性のある移行履歴の確認はスキップされます。

migrate

データベースの状態を現在のモデルと移行のセットと同期します。移行、アプリとの関係などについては、移行ドキュメントで詳しく説明されています。

このコマンドの動作は、提供された引数に応じて変わります。

引数なし：すべてのアプリですべての移行が実行されます。
<app_label>：指定されたアプリでは、最新の移行までの移行が実行されます。これには、依存関係のために、他のアプリの移行の実行も含まれる場合があります。
<app_label> <migrationname>：データベーススキーマを、指定された移行が適用される状態にしますが、同じアプリでのそれ以降の移行は適用されません。名前付き移行を過ぎて以前に移行したことがある場合、これには適用されない移行が含まれる場合があります。移行名のプレフィックスを使用できます。例： 0001、指定されたアプリ名で一意である限り。 zeroという名前を使用して、完全に元に戻します。アプリに適用されたすべての移行を元に戻します。

警告

移行を適用解除すると、<app_label>に関係なく、依存するすべての移行も適用されなくなります。 --planを使用して、どの移行が適用されないかを確認できます。

移行するデータベースを指定します。デフォルトはdefaultです。

データベーススキーマを変更するために実際にSQLを実行せずに、（上記のルールに従って）ターゲットへの移行を適用済みとしてマークします。

これは、上級ユーザーが手動で変更を適用している場合に、現在の移行状態を直接操作することを目的としています。 --fakeを使用すると、移行状態テーブルが移行を正しく実行するために手動リカバリが必要な状態になるリスクがあることに注意してください。

その移行ですべての CreateModel 操作によって作成されたすべてのモデルの名前を持つすべてのデータベーステーブルがすでに存在する場合、Djangoがアプリの初期移行をスキップできるようにします。このオプションは、移行の使用がすでに存在するデータベースに対して最初に移行を実行するときに使用することを目的としています。ただし、このオプションは、一致するテーブル名以外に一致するデータベーススキーマをチェックしないため、既存のスキーマが最初の移行で記録されたものと一致することが確実な場合にのみ安全に使用できます。

指定されたmigrateコマンドに対して実行される移行操作を示します。

移行せずにアプリのテーブルを作成できます。これは推奨されませんが、数百のモデルを含む大規模なプロジェクトでは、移行フレームワークが遅すぎる場合があります。

すべてのユーザープロンプトを抑制します。プロンプトの例は、古いコンテンツタイプの削除について尋ねています。

バージョン3.1の新機能。

適用されていない移行が検出された場合、migrateをゼロ以外のステータスで終了させます。

runserver

ローカルマシンで軽量開発Webサーバーを起動します。デフォルトでは、サーバーはIPアドレス127.0.0.1のポート8000で実行されます。 IPアドレスとポート番号を明示的に渡すことができます。

このスクリプトを通常の特権（推奨）を持つユーザーとして実行すると、低いポート番号でポートを開始するためのアクセス権がない可能性があります。低いポート番号はスーパーユーザー（root）用に予約されています。

このサーバーは、：setting： `WSGI_APPLICATION` 設定で指定されたWSGIアプリケーションオブジェクトを使用します。

このサーバーを本番環境で使用しないでください。セキュリティ監査やパフォーマンステストは実施されていません。（そしてそれはそれがとどまる方法です。私たちはWebサーバーではなくWebフレームワークを作成するビジネスを行っているため、本番環境を処理できるようにこのサーバーを改善することはDjangoの範囲外です。）

開発サーバーは、必要に応じて、リクエストごとにPythonコードを自動的に再読み込みします。コードの変更を有効にするためにサーバーを再起動する必要はありません。ただし、ファイルの追加などの一部のアクションでは再起動がトリガーされないため、このような場合はサーバーを再起動する必要があります。

LinuxまたはMacOSを使用していて、 pywatchman サービスと Watchman サービスの両方をインストールする場合、カーネル信号を使用してサーバーを自動リロードします（ファイル変更タイムスタンプを毎秒ポーリングするのではありません）。これにより、大規模なプロジェクトでのパフォーマンスが向上し、コード変更後の応答時間が短縮され、変更検出がより堅牢になり、電力使用量が削減されます。 Djangoはpywatchman 1.2.0以降をサポートしています。

多くのファイルを含む大きなディレクトリは、パフォーマンスの問題を引き起こす可能性があります

node_modulesのようなPython以外の大きなディレクトリを含むプロジェクトでWatchmanを使用する場合、最適なパフォーマンスを得るためにこのディレクトリを無視することをお勧めします。これを行う方法については、ウォッチマンのドキュメントを参照してください。

警備員のタイムアウト

DJANGO_WATCHMAN_TIMEOUT

Watchmanクライアントのデフォルトのタイムアウトは5秒です。 DJANGO_WATCHMAN_TIMEOUT 環境変数を設定することで変更できます。

サーバーを起動すると、サーバーの実行中にPythonコードを変更するたびに、システムチェックフレームワークはDjangoプロジェクト全体でいくつかの一般的なエラーをチェックします（：djadmin： `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アプリが有効になっている場合（新しいプロジェクトではデフォルト）、：djadmin： `runserver` コマンドは独自の runserver コマンドで上書きされます。

サーバーの各要求と応答のログは、 django.server ロガーに送信されます。

自動リローダーを無効にします。これは、特定のPythonモジュールがすでにメモリにロードされている場合、サーバーの実行中に行ったPythonコードの変更は無効になることを意味します。

開発サーバーでのスレッドの使用を無効にします。サーバーはデフォルトでマルチスレッド化されています。

開発サーバーにIPv6を使用します。これにより、デフォルトのIPアドレスが127.0.0.1から::1に変更されます。

異なるポートとアドレスの使用例

IPアドレス127.0.0.1のポート8000：

django-admin runserver

IPアドレス1.2.3.4のポート8000：

django-admin runserver 1.2.3.4:8000

IPアドレス127.0.0.1のポート7000：

django-admin runserver 7000

IPアドレス1.2.3.4のポート7000：

django-admin runserver 1.2.3.4:7000

IPv6アドレス::1のポート8000：

django-admin runserver -6

IPv6アドレス::1のポート7000：

django-admin runserver -6 7000

IPv6アドレス2001:0db8:1234:5678::9のポート7000：

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

ホストlocalhostのIPv4アドレスのポート8000：

django-admin runserver localhost:8000

ホストlocalhostのIPv6アドレスのポート8000：

django-admin runserver -6 localhost:8000

開発サーバーで静的ファイルを提供する

デフォルトでは、開発サーバーはサイトの静的ファイル（CSSファイル、画像、：setting： `MEDIA_URL` の下にあるものなど）を提供しません。静的メディアを提供するようにDjangoを構成する場合は、以下をお読みください。静的ファイルの管理（例：画像、JavaScript、CSS）。

sendtestemail

指定された受信者にテストメールを送信します（Djangoを介したメール送信が機能していることを確認するため）。例えば：

django-admin sendtestemail [email protected] [email protected]

いくつかのオプションがあり、それらを任意に組み合わせて使用できます。

mail_managers（）を使用して、：setting： `MANAGERS` で指定されたメールアドレスをメールで送信します。

mail_admins（）を使用して、：setting： `ADMINS` で指定されたメールアドレスをメールで送信します。

shell

Pythonインタラクティブインタプリタを起動します。

使用するシェルを指定します。デフォルトでは、Djangoは IPython または bpython のいずれかがインストールされている場合、それらを使用します。両方がインストールされている場合は、どちらを使用するかを指定します。

IPython：

django-admin shell -i ipython

bpython：

django-admin shell -i bpython

「リッチ」シェルがインストールされているが、「プレーン」Pythonインタープリターの使用を強制したい場合は、次のように、インターフェース名としてpythonを使用します。

django-admin shell -i python

「プレーンな」Pythonインタープリターの起動スクリプトの読み取りを無効にします。デフォルトでは、 PYTHONSTARTUP環境変数または~/.pythonrc.pyスクリプトが指すスクリプトが読み取られます。

次のように、コマンドを文字列として渡してDjangoとして実行できます。

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

標準入力にコードを渡して実行することもできます。例えば：

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

Windowsでは、そのプラットフォームでのselect.select()の実装制限により、REPLが出力されます。

showmigrations

プロジェクト内のすべての移行を表示します。次の2つの形式のいずれかを選択できます。

Djangoが認識しているすべてのアプリ、各アプリで利用可能な移行、および各移行が適用されているかどうかを一覧表示します（移行名の横に[X]でマークされています）。 --verbosityが2以上の場合、適用された日時も表示されます。

移行されていないアプリも一覧表示されますが、その下に(no migrations)が印刷されています。

これがデフォルトの出力フォーマットです。

移行を適用するためにDjangoが従う移行計画を示します。 --listと同様に、適用された移行は[X]でマークされます。 --verbosityが2以上の場合、移行のすべての依存関係も表示されます。

app_labelの引数は出力を制限しますが、提供されたアプリの依存関係も含まれる場合があります。

調べるデータベースを指定します。デフォルトはdefaultです。

sqlflush

：djadmin： `flush` コマンドに対して実行されるSQLステートメントを出力します。

SQLを印刷するデータベースを指定します。デフォルトはdefaultです。

sqlmigrate

名前付き移行のSQLを出力します。これにはアクティブなデータベース接続が必要であり、これを使用して制約名を解決します。つまり、後で適用するデータベースのコピーに対してSQLを生成する必要があります。

sqlmigrateは出力を色付けしないことに注意してください。

移行を適用解除するためのSQLを生成します。デフォルトでは、作成されるSQLは、順方向に移行を実行するためのものです。

SQLを生成するデータベースを指定します。デフォルトはdefaultです。

sqlsequencereset

指定されたアプリ名のシーケンスをリセットするためのSQLステートメントを出力します。

シーケンスは、自動的にインクリメントされるフィールドで次に使用可能な数を追跡するために一部のデータベースエンジンで使用されるインデックスです。

このコマンドを使用してSQLを生成します。これにより、シーケンスが自動的にインクリメントされたフィールドデータと同期していない場合が修正されます。

SQLを印刷するデータベースを指定します。デフォルトはdefaultです。

squashmigrations

可能であれば、app_labelからmigration_nameまでの移行を、より少ない移行に押しつぶします。結果として生じる押しつぶされた移行は、押しつぶされていない移行と安全に共存できます。詳細については、スカッシュマイグレーションをお読みください。

start_migration_nameが指定されている場合、Djangoには、この移行以降の移行のみが含まれます。これは、 RunPython および django.db.migrations.operations.RunSQL 移行操作の押しつぶしの制限を緩和するのに役立ちます。

押しつぶされた移行を生成するときにオプティマイザを無効にします。デフォルトでは、Djangoは移行の操作を最適化して、結果のファイルのサイズを縮小しようとします。このプロセスが失敗したり、誤った移行を作成したりする場合は、このオプションを使用してください。ただし、最適化は安全を目的としているため、動作に関するDjangoバグレポートも提出してください。

すべてのユーザープロンプトを抑制します。

押しつぶされた移行の名前を設定します。省略した場合、名前は最初と最後の移行に基づいており、その間に_squashed_があります。

Djangoバージョンとタイムスタンプヘッダーなしで押しつぶされた移行ファイルを生成します。

startapp

現在のディレクトリまたは指定された宛先に、指定されたアプリ名のDjangoアプリディレクトリ構造を作成します。

デフォルトでは、：source： `新しいディレクトリ ` が含まれていますmodels.pyファイルおよびその他のアプリテンプレートファイル。アプリ名のみを指定すると、現在の作業ディレクトリにアプリディレクトリが作成されます。

オプションの宛先が指定されている場合、Djangoは新しいディレクトリを作成するのではなく、その既存のディレクトリを使用します。 '。'を使用できます現在の作業ディレクトリを示します。

例えば：

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

カスタムアプリテンプレートファイルを含むディレクトリへのパス、または非圧縮アーカイブ（.tar）または圧縮アーカイブ（.tar.gz、.tar.bz2、.tar.xz、.tar.lzma、.tgz、.tbz2、.txz、.tlz、.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

アプリテンプレートのどのファイル拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトはpyです。

（--extensionに一致するファイルに加えて）アプリテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。

一致するすべてのファイルに使用されるテンプレートコンテキストは次のとおりです。

startappコマンドに渡されるオプション（コマンドでサポートされているオプションの中で）
app_name –コマンドに渡されたアプリ名
app_directory –新しく作成されたアプリのフルパス
camel_case_app_name –キャメルケース形式のアプリ名
docs_version –ドキュメントのバージョン：'dev'または'1.x'
django_version – Djangoのバージョン、例： '2.0.3'

警告

アプリテンプレートファイルがDjangoテンプレートエンジン（デフォルトではすべての*.pyファイル）でレンダリングされると、Djangoは含まれているすべての漂遊テンプレート変数も置き換えます。たとえば、Pythonファイルの1つに、テンプレートレンダリングに関連する特定の機能を説明するドキュメント文字列が含まれている場合、誤った例になる可能性があります。

この問題を回避するには、：ttag： `templatetag` テンプレートタグを使用して、テンプレート構文のさまざまな部分を「エスケープ」できます。

さらに、パッケージシステムが無効な*.pyファイルをバイトコンパイルしようとするのを防ぎながら、Djangoテンプレート言語構文を含むPythonテンプレートファイルを許可するために、.py-tplで終わるテンプレートファイルの名前が.py。

startproject

現在のディレクトリまたは指定された宛先に、指定されたプロジェクト名のDjangoプロジェクトディレクトリ構造を作成します。

デフォルトでは、：source： `新しいディレクトリ ` 含まれていますmanage.pyおよびプロジェクトパッケージ（settings.py およびその他のファイル）。

プロジェクト名のみを指定した場合、プロジェクトディレクトリとプロジェクトパッケージの両方に<projectname>という名前が付けられ、プロジェクトディレクトリが現在の作業ディレクトリに作成されます。

オプションの宛先が指定されている場合、Djangoはその既存のディレクトリをプロジェクトディレクトリとして使用し、その中にmanage.pyとプロジェクトパッケージを作成します。使用する '。' 現在の作業ディレクトリを示します。

例えば：

django-admin startproject myproject /Users/jezdez/Code/myproject_repo

カスタムプロジェクトテンプレートのディレクトリ、ファイルパス、またはURLを指定します。例と使用法については、startapp --templateのドキュメントを参照してください。

プロジェクトテンプレートのどのファイル拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトはpyです。

（--extensionに一致するファイルに加えて）プロジェクトテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。

使用されるテンプレートコンテキストは次のとおりです。

startprojectコマンドに渡されるオプション（コマンドでサポートされているオプションの中で）
project_name –コマンドに渡されたプロジェクト名
project_directory –新しく作成されたプロジェクトのフルパス
secret_key – ：setting： `SECRET_KEY` 設定のランダムキー
docs_version –ドキュメントのバージョン：'dev'または'1.x'
django_version – Djangoのバージョン、例： '2.0.3'

：djadmin： `startapp` で説明されているように、レンダリング警告も参照してください。

test

インストールされているすべてのアプリのテストを実行します。詳細については、 Django でのテストを参照してください。

テストの実行を停止し、テストが失敗した直後に失敗を報告します。

テストの実行に使用されるテストランナークラスを制御します。この値は、：setting： `TEST_RUNNER` 設定によって提供される値をオーバーライドします。

すべてのユーザープロンプトを抑制します。一般的なプロンプトは、既存のテストデータベースの削除に関する警告です。

テストランナーオプション

testコマンドは、指定された--testrunnerに代わってオプションを受け取ります。デフォルトのテストランナーのオプションは次のとおりです： DiscoverRunner 。

テストの実行間でテストデータベースを保持します。これには、作成アクションと破棄アクションの両方をスキップできるという利点があり、特に大規模なテストスイートのテストを実行する時間を大幅に短縮できます。テストデータベースが存在しない場合は、最初の実行時に作成され、その後の実行ごとに保持されます。でない限り：setting： `MIGRATE ` テスト設定はFalse 、適用されていない移行は、テストスイートを実行する前にテストデータベースにも適用されます。

テストケースを逆の実行順序で並べ替えます。これは、適切に分離されていないテストの副作用をデバッグするのに役立つ場合があります。このオプションを使用すると、テストクラスによるグループ化が保持されます。

テストを実行する前に、：setting： `DEBUG` 設定をTrueに設定します。これは、テストの失敗のトラブルシューティングに役立つ場合があります。

失敗したテストに対して SQLロギングを有効にします。 --verbosityが2の場合、合格したテストのクエリも出力されます。

DJANGO_TEST_PROCESSES

別々の並列プロセスでテストを実行します。最新のプロセッサには複数のコアがあるため、これによりテストの実行が大幅に高速化されます。

デフォルトでは、--parallelは、multiprocessing.cpu_count()に従って、コアごとに1つのプロセスを実行します。オプションの値として指定することにより、プロセスの数を調整できます。 --parallel=4、または DJANGO_TEST_PROCESSES 環境変数を設定します。

Djangoは、テストケース（unittest.TestCaseサブクラス）をサブプロセスに配布します。構成されたプロセスよりもテストケースが少ない場合、Djangoはそれに応じてプロセスの数を減らします。

各プロセスは独自のデータベースを取得します。異なるテストケースが同じリソースにアクセスしないようにする必要があります。たとえば、ファイルシステムにアクセスするテストケースは、独自に使用するための一時ディレクトリを作成する必要があります。

ノート

並行して実行できないテストクラスがある場合は、SerializeMixinを使用してそれらを順番に実行できます。テストクラスを順番に実行するように強制するを参照してください。

このオプションでは、トレースバックを正しく表示するために、サードパーティのtblibパッケージが必要です。

$ python -m pip install tblib

この機能はWindowsでは利用できません。 Oracleデータベースのバックエンドでも機能しません。

テストのデバッグ中にpdbを使用する場合は、並列実行を無効にする必要があります（--parallel=1）。そうでない場合は、bdb.BdbQuitのようなものが表示されます。

警告

テストの並列化が有効になっていてテストが失敗した場合、Djangoは例外トレースバックを表示できない場合があります。これにより、デバッグが困難になる可能性があります。この問題が発生した場合は、影響を受けるテストを並列化せずに実行して、失敗のトレースバックを確認してください。

これは既知の制限です。これは、プロセス間でオブジェクトを交換するためにオブジェクトをシリアル化する必要があるために発生します。詳細については、 python：pickle-picklable を参照してください。

--tag TAGS

指定されたタグでマークされたテストのみを実行します。複数回指定してtest --exclude-tagと組み合わせることができます。

--exclude-tag EXCLUDE_TAGS

指定されたタグでマークされたテストを除外します。複数回指定してtest --tagと組み合わせることができます。

unittest's -k optionと同じ方法で、テスト名のパターンに一致するテストメソッドとクラスを実行します。複数回指定できます。

Python3.7以降

この機能は、Python3.7以降でのみ使用できます。

テストエラーまたは失敗のたびにpdbデバッガーを生成します。インストールしている場合は、代わりにipdbが使用されます。

バージョン3.1の新機能。

unittest's --buffer optionと同じように、テストに合格するために出力（stdoutおよびstderr）を破棄します。

バージョン3.2の新機能。

Djangoは、テストの開始時に自動的にfaulthandler.enable()を呼び出します。これにより、インタープリターがクラッシュした場合にトレースバックを出力できます。この動作を無効にするには、--no-faulthandlerを渡します。

バージョン3.2の新機能。

データベースのセットアップや合計実行時間を含むタイミングを出力します。

testserver

指定されたフィクスチャからのデータを使用して、Django開発サーバーを実行します（：djadmin： `runserver` のように）。

たとえば、次のコマンドは次のとおりです。

django-admin testserver mydata.json

…次の手順を実行します。

テストデータベースの説明に従って、テストデータベースを作成します。
指定されたフィクスチャからのフィクスチャデータをテストデータベースに入力します。（フィクスチャの詳細については、上記の：djadmin： `loaddata` のドキュメントを参照してください。）
Django開発サーバーを実行し（：djadmin： `runserver` のように）、本番データベースではなく、この新しく作成されたテストデータベースをポイントします。

これは、いくつかの点で役立ちます。

ビューが特定のフィクスチャデータでどのように動作するかについて単体テストを記述している場合、testserverを使用してWebブラウザーのビューを手動で操作できます。
Djangoアプリケーションを開発していて、操作したいデータベースの「元の」コピーがあるとします。データベースをフィクスチャにダンプし（上記で説明した：djadmin： `dumpdata` コマンドを使用）、testserverを使用してそのデータでWebアプリケーションを実行できます。この配置により、データの変更はテストデータベースに対してのみ行われることを認識し、データを任意の方法で混乱させる柔軟性が得られます。

このサーバーは、Pythonソースコードへの変更を自動的に検出しないことに注意してください（：djadmin： `runserver` のように）。ただし、テンプレートへの変更は検出します。

デフォルトの127.0.0.1:8000とは異なるポート、またはIPアドレスとポートを指定します。この値はまったく同じ形式に従い、：djadmin： `runserver` コマンドの引数とまったく同じ機能を果たします。

例：

fixture1およびfixture2を使用してポート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

すべてのユーザープロンプトを抑制します。一般的なプロンプトは、既存のテストデータベースの削除に関する警告です。

アプリケーションが提供するコマンド

一部のコマンドは、django.contrib そのアプリケーション実装彼らはされています：setting： `enabled ` 。このセクションでは、アプリケーションごとにグループ化されたものについて説明します。

django.contrib.auth

changepassword

このコマンドは、Djangoの認証システム（django.contrib.auth）がインストールされている場合にのみ使用できます。

ユーザーのパスワードを変更できます。指定されたユーザーの新しいパスワードを2回入力するように求められます。エントリが同一の場合、これはすぐに新しいパスワードになります。ユーザーを指定しない場合、コマンドは、ユーザー名が現在のユーザーと一致するパスワードを変更しようとします。

ユーザーを照会するデータベースを指定します。デフォルトはdefaultです。

使用例：

django-admin changepassword ringo

createsuperuser

DJANGO_SUPERUSER_PASSWORD

このコマンドは、Djangoの認証システム（django.contrib.auth）がインストールされている場合にのみ使用できます。

スーパーユーザーアカウント（すべての権限を持つユーザー）を作成します。これは、最初のスーパーユーザーアカウントを作成する必要がある場合、またはサイトのスーパーユーザーアカウントをプログラムで生成する必要がある場合に役立ちます。

インタラクティブに実行すると、このコマンドは新しいスーパーユーザーアカウントのパスワードの入力を求めます。非対話的に実行する場合は、 DJANGO_SUPERUSER_PASSWORD 環境変数を設定してパスワードを指定できます。それ以外の場合、パスワードは設定されず、パスワードが手動で設定されるまでスーパーユーザーアカウントはログインできません。

非対話型モードでは、 USERNAME_FIELD および必須フィールド（ REQUIRED_FIELDS にリストされている）は、コマンドライン引数によってオーバーライドされない限り、DJANGO_SUPERUSER_<uppercase_field_name>環境変数にフォールバックします。たとえば、emailフィールドを提供するには、DJANGO_SUPERUSER_EMAIL環境変数を使用できます。

すべてのユーザープロンプトを抑制します。抑制されたプロンプトを自動的に解決できない場合、コマンドはエラーコード1で終了します。

新しいアカウントのユーザー名と電子メールアドレスは、コマンドラインの--usernameおよび--email引数を使用して指定できます。これらのいずれかが提供されていない場合、createsuperuserはインタラクティブに実行するときにそれを要求します。

スーパーユーザーオブジェクトが保存されるデータベースを指定します。

データの入力と検証をカスタマイズする場合は、管理コマンドをサブクラス化し、get_input_data()をオーバーライドできます。既存の実装とメソッドのパラメータの詳細については、ソースコードを参照してください。たとえば、 REQUIRED_FIELDS にForeignKeyがあり、既存のインスタンスの主キーを入力する代わりにインスタンスの作成を許可したい場合に便利です。

django.contrib.contenttypes

remove_stale_contenttypes

このコマンドは、Djangoの contenttypes app （ django.contrib.contenttypes ）がインストールされている場合にのみ使用できます。

データベース内の古いコンテンツタイプを（削除されたモデルから）削除します。削除されたコンテンツタイプに依存するオブジェクトもすべて削除されます。削除を続行してもよいことを確認する前に、削除されたオブジェクトのリストが表示されます。

使用するデータベースを指定します。デフォルトはdefaultです。

バージョン3.1の新機能。

：setting： `INSTALLED_APPS` から削除された、以前にインストールされたアプリからのものを含む古いコンテンツタイプを削除します。デフォルトはFalseです。

django.contrib.gis

ogrinspect

このコマンドは、 GeoDjango （django.contrib.gis）がインストールされている場合にのみ使用できます。

そのを参照してください：djadmin： `説明 ` GeoDjangoのドキュメントにあります。

django.contrib.sessions

clearsessions

cronジョブとして実行することも、直接実行して期限切れのセッションをクリーンアップすることもできます。

django.contrib.sitemaps

ping_google

このコマンドは、サイトマップフレームワーク（django.contrib.sitemaps）がインストールされている場合にのみ使用できます。

そのを参照してください：djadmin： `説明 ` サイトマップのドキュメントにあります。

django.contrib.staticfiles

collectstatic

このコマンドは、静的ファイルアプリケーション（django.contrib.staticfiles）がインストールされている場合にのみ使用できます。

そのを参照してください：djadmin： `説明 ` の中に staticfiles ドキュメンテーション。

findstatic

このコマンドは、静的ファイルアプリケーション（django.contrib.staticfiles）がインストールされている場合にのみ使用できます。

そのを参照してください：djadmin： `説明 ` の中に staticfiles ドキュメンテーション。

デフォルトオプション

一部のコマンドでは独自のカスタムオプションが許可されている場合がありますが、すべてのコマンドではデフォルトで次のオプションが許可されています。

指定されたファイルシステムパスをPython インポート検索パスに追加します。これが指定されていない場合、django-adminは PYTHONPATH環境変数を使用します。

このオプションは、Pythonパスの設定を自動的に処理するため、manage.pyでは不要です。

使用例：

django-admin migrate --pythonpath='/home/djangoprojects/myproject'

使用する設定モジュールを指定します。設定モジュールはPythonパッケージ構文である必要があります。 mysite.settings。これが指定されていない場合、django-adminは DJANGO_SETTINGS_MODULE 環境変数を使用します。

このオプションは、デフォルトで現在のプロジェクトのsettings.pyを使用するため、manage.pyでは不要です。

使用例：

django-admin migrate --settings=mysite.settings

CommandError が発生すると、完全なスタックトレースを表示します。デフォルトでは、django-adminは、CommandErrorが発生したときにエラーメッセージを表示し、その他の例外については完全なスタックトレースを表示します。

このオプションは、：djadmin： `runserver` では無視されます。

使用例：

django-admin migrate --traceback

コマンドがコンソールに出力する通知およびデバッグ情報の量を指定します。

0は出力がないことを意味します。
1は通常の出力を意味します（デフォルト）。
2は、詳細な出力を意味します。
3は、非常に詳細な出力を意味します。

このオプションは、：djadmin： `runserver` では無視されます。

使用例：

django-admin migrate --verbosity 2

色付きのコマンド出力を無効にします。一部のコマンドは、出力を色付けするようにフォーマットします。たとえば、エラーは赤でコンソールに出力され、SQLステートメントは構文が強調表示されます。

使用例：

django-admin runserver --no-color

構文の色付けで説明されているように、コマンド出力が無効になる場合は、コマンド出力の色付けを強制します。たとえば、色付きの出力を別のコマンドにパイプしたい場合があります。

コマンドを実行する前に、実行中のシステムチェックをスキップします。このオプションは、 require_system_checks コマンド属性が空のリストまたはタプルでない場合にのみ使用できます。

使用例：

django-admin migrate --skip-checks

余分な素敵さ

構文の色付け

DJANGO_COLORS

django-admin / manage.pyコマンドは、端末がANSI色の出力をサポートしている場合、かなり色分けされた出力を使用します。 --force-colorオプションが使用されていない限り、コマンドの出力を別のプログラムにパイプする場合、カラーコードは使用されません。

Windowsサポート

Windows 10では、 Windows Terminal アプリケーション、 VS Code 、およびPowerShell（仮想端末処理が有効になっている）で色付きの出力が可能であり、デフォルトでサポートされています。

Windowsでは、レガシーcmd.exeネイティブコンソールはANSIエスケープシーケンスをサポートしていないため、デフォルトではカラー出力はありません。この場合、2つのサードパーティライブラリのいずれかが必要です。

colorama をインストールします。これは、ANSIカラーコードをWindowsAPI呼び出しに変換するPythonパッケージです。 Djangoコマンドはその存在を検出し、Unixベースのプラットフォームと同じようにそのサービスを利用して出力に色を付けます。 coloramaはpip経由でインストールできます：
```
...\> py -m pip install colorama
```
ANSICON をインストールします。これは、cmd.exeがANSIカラーコードを処理できるようにするサードパーティツールです。 Djangoコマンドはその存在を検出し、Unixベースのプラットフォームと同じようにそのサービスを利用して出力に色を付けます。

端末の色をサポートしているが、Djangoでサポートされていると自動的に検出されない、Windows上の他の最新の端末環境は、適切な環境変数ANSICON="on"を設定することにより、ANSICONのインストールを「偽造」する可能性があります。

バージョン3.2で変更： Windowsでの構文の色付けのサポートが更新されました。

カスタムカラー

構文の強調表示に使用される色はカスタマイズできます。 Djangoには3つのカラーパレットが付属しています。

dark、黒い背景に白いテキストを表示する端末に適しています。これはデフォルトのパレットです。
light、白い背景に黒いテキストを表示する端末に適しています。
nocolor、構文の強調表示を無効にします。

DJANGO_COLORS 環境変数を設定してパレットを選択し、使用するパレットを指定します。たとえば、UnixまたはOS / XBASHシェルでlightパレットを指定するには、コマンドプロンプトで次のコマンドを実行します。

export DJANGO_COLORS="light"

使用する色をカスタマイズすることもできます。 Djangoは、色が使用されるいくつかの役割を指定します。

error-重大なエラー。
notice-マイナーエラー。
success-成功。
warning-警告。
sql_field -SQLのモデルフィールドの名前。
sql_coltype -SQLのモデルフィールドのタイプ。
sql_keyword -SQLキーワード。
sql_table -SQLでのモデルの名前。
http_info -1XXHTTP情報サーバーの応答。
http_success -2XXHTTP成功サーバーの応答。
http_not_modified -304HTTP未変更サーバーの応答。
http_redirect -304以外の3XXHTTPリダイレクトサーバーの応答。
http_not_found -404 HTTP NotFoundサーバーの応答。
http_bad_request -404以外の4XXHTTP BadRequestサーバー応答。
http_server_error -5XXHTTPサーバーエラー応答。
migrate_heading-移行管理コマンドの見出し。
migrate_label-移行名。

これらの各役割には、次のリストから特定の前景色と背景色を割り当てることができます。

black
red
green
yellow
blue
magenta
cyan
white

これらの各色は、次の表示オプションを使用して変更できます。

bold
underscore
blink
reverse
conceal

色の仕様は、次のいずれかのパターンに従います。

role=fg
role=fg/bg
role=fg,option,option
role=fg/bg,option,option

ここで、roleは有効な色の役割の名前、fgは前景色、bgは背景色、各optionは色の1つです。オプションの変更。次に、複数の色の仕様がセミコロンで区切られます。例えば：

export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

エラーは青に黄色の点滅を使用して表示され、通知はマゼンタを使用して表示されるように指定します。他のすべての色の役割は色なしのままになります。

ベースパレットを拡張して色を指定することもできます。色の指定にパレット名を入力すると、そのパレットによって示されるすべての色が読み込まれます。そう：

export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

ライトカラーパレットのすべての色の使用を指定します。はを除き、指定されたとおりに上書きされるエラーと通知の色を除きます。

Bashの完了

Bashシェルを使用する場合は、Djangoソースディストリビューションのextras/django_bash_completionにあるDjangobash完了スクリプトをインストールすることを検討してください。 django-adminおよびmanage.pyコマンドのタブ補完が有効になるため、たとえば…

django-adminと入力します。
[TAB]を押して、使用可能なすべてのオプションを表示します。
sql、次に[TAB]と入力して、名前がsqlで始まる使用可能なすべてのオプションを表示します。

カスタマイズされたアクションを追加する方法については、カスタムdjango-adminコマンドの記述[X44X]を参照してください。

コードから管理コマンドを実行する

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)

上記のinteractiveオプションでわかるように、引数をとらないコマンドオプションは、TrueまたはFalseのキーワードとして渡されることに注意してください。

名前付き引数は、次の構文のいずれかを使用して渡すことができます。

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

django-adminまたはmanage.pyの代わりにcall_command()を使用すると、一部のコマンドオプションの名前が異なります。たとえば、django-admin createsuperuser --no-inputはcall_command('createsuperuser', interactive=False)に変換されます。 call_command()に使用するキーワード引数名を見つけるには、parser.add_argument()に渡されたdest引数のコマンドのソースコードを確認してください。

複数のオプションを使用するコマンドオプションには、次のリストが渡されます。

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

call_command()関数の戻り値は、コマンドのhandle()メソッドの戻り値と同じです。

出力リダイレクト

すべてのコマンドがstdoutおよびstderrオプションをサポートしているため、標準出力およびエラーストリームをリダイレクトできることに注意してください。たとえば、次のように書くことができます。

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

django-adminおよびmanage.py—Djangoのドキュメント

django-adminおよびmanage.py

使用法

ランタイムヘルプの取得

アプリ名

バージョンの決定

デバッグ出力の表示

使用可能なコマンド

check

compilemessages

createcachetable

dbshell

diffsettings

dumpdata

備品の圧縮

flush

inspectdb

データベース固有の注意事項

オラクル

PostgreSQL

loaddata

「フィクスチャ」とは何ですか？

圧縮された器具

データベース固有のフィクスチャ

stdinからフィクスチャをロードしています

makemessages

makemigrations

migrate

runserver

異なるポートとアドレスの使用例

開発サーバーで静的ファイルを提供する

sendtestemail

shell

showmigrations

sqlflush

sqlmigrate

sqlsequencereset

squashmigrations

startapp

startproject

test

テストランナーオプション

testserver

アプリケーションが提供するコマンド

django.contrib.auth

changepassword

createsuperuser

django.contrib.contenttypes

remove_stale_contenttypes

django.contrib.gis

ogrinspect

django.contrib.sessions

clearsessions

django.contrib.sitemaps

ping_google

django.contrib.staticfiles

collectstatic

findstatic

デフォルトオプション

余分な素敵さ

構文の色付け

Windowsサポート

カスタムカラー

Bashの完了

コードから管理コマンドを実行する

出力リダイレクト