django-admin
と manage.py
¶
django-admin
は Django の管理タスクのためのコマンドラインユーティリティです。このドキュメントでは、その機能の全体を一通り説明します。
さらに、manage.py
は各 Django プロジェクト内に自動的に作成されます。jango-admin
と同じことができますが、DJANGO_SETTINGS_MODULE
を設定することもでき、プロジェクトの settings.py
を指定できます。
Django を pip
経由でインストールした場合、 django-admin
はシステムパス上に設定されているはずです。もしシステムパスにない場合、仮想環境が有効になっていることを確認してください。
通常、単体の Django プロジェクトを用いる場合、django-admin
よりも manage.py
の方が簡単に利用できます。もし複数の Django 設定ファイル間での切り替えが必要な場合は、django-admin
を DJANGO_SETTINGS_MODULE
もしくは --settings
オプションと共に利用してください。
本項ではコマンドラインの実行例は一貫して django-admin
を使用しますが、実行例は全て manage.py
もしくは python -m django
でも同様に利用可能です。
使い方¶
$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]
...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]
command
にはこのドキュメントに一覧されたコマンドの1つでなければなりません。options
はオプションで、与えられたコマンドで利用できる 0 個以上のオプションを指定します。
ランタイムのヘルプを表示する¶
-
django-admin help
¶
django-admin help
を実行すると、使用方法の情報と、各アプリケーションが提供するコマンドのリストが表示されます。
django-admin help --commands
を実行すると、利用可能な全てのコマンドの一覧が表示されます。
django-admin help <command>
を実行すると、与えられたコマンドの説明と利用可能なオプションの一覧が表示されます。
アプリ名¶
多くのコマンドは「アプリ名」のリストを取ります。1つの「アプリ名」はモデルを含むパッケージのベースネーム (basename) となります。たとえば、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
-
--database
DATABASE
¶
データベースアクセスが必要なチェックを実行するには、次のようにデータベースを指定します。
django-admin check --database default --database other
デフォルトでは、これらのチェックは実行されません。
-
--list-tags
¶
利用可能なタグを一覧します。
-
--deploy
¶
デプロイメントの設定にだけ関係のある、いくつかの追加チェックを有効化します。
このオプションはローカルの開発環境で使えますが、ローカルの開発の設定モジュールは本番の設定の多くがないかもしれないため、おそらく DJANGO_SETTINGS_MODULE
環境変数を設定するか、--settings
オプションを渡すことで、異なる設定モジュールを指定したくなるでしょう。
django-admin check --deploy --settings=production_settings
あるいは、(--settings
を省略して) 正しい設定が使用されていることを検証するために、本番かステージングのデプロイメントで直接実行することも可能です。
-
--fail-level
{CRITICAL,ERROR,WARNING,INFO,DEBUG}
¶
0 以外のステータスでコマンドを終了させるメッセージレベルを指定します。デフォルトは ERROR
です。
compilemessages
¶
-
django-admin compilemessages
¶
ビルトインの gettext サポートで使用できるように、makemessages
が作成した .po
ファイルを .mo
ファイルにコンパイルします。詳しくは 国際化とローカライズ を参照してください。
-
--locale
LOCALE
,
-l
LOCALE
¶
処理する locale を指定します。提供されなかった場合、すべてのロケールが処理されます。
-
--exclude
EXCLUDE
,
-x
EXCLUDE
¶
処理から除外する locale を指定します。提供されなかった場合、どのロケールも除外されません。
-
--use-fuzzy
,
-f
¶
fuzzy な翻訳 をコンパイルされたファイルに含めます
使用例:
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
-
--ignore
PATTERN
,
-i
PATTERN
¶
与えられた glob
スタイルのパターンに一致するディレクトリを無視します。 何度も無視するためには複数回使用してください。
使用例:
django-admin compilemessages --ignore=cache --ignore=outdated/*/locale
createcachetable
¶
-
django-admin createcachetable
¶
設定ファイルからの情報を使用して、データベース キャッシュ バックエンドで使用するためのキャッシュテーブルを作成します。詳細な情報については、 Django のキャッシュフレームワーク を参照してください。
-
--database
DATABASE
¶
キャッシュテーブルを作成するデータベースを指定します。デフォルトは default
です。
-
--dry-run
¶
実行予定の SQL を、実際には実行せずに出力します。これにより、SQL をカスタマイズしたり、マイグレーション フレームワークを使用できます。
dbshell
¶
-
django-admin dbshell
¶
USER
や PASSWORD
などの設定で指定されたコネクション パラメータを使用して、ENGINE
設定で指定されたデータベースエンジン用のコマンドライン クライアントを実行します。
- PostgreSQL の場合、
psql
コマンドライン クライアントが実行されます。 - MySQL の場合、
mysql
コマンドライン クライアントが実行されます。 - SQLite の場合、
sqlite3
コマンドライン クライアントが実行されます。 - Oracle の場合、
sqlplus
コマンドライン クライアントが実行されます。
このコマンドは、プログラム名 (psql
、mysql
、sqlite3
、sqlplus
) の呼び出しで正しい場所にあるプログラムが見つかるように PATH
が設定されているを想定しています。プログラムの場所を手動で指定する方法はありません。
-
--database
DATABASE
¶
シェルをオープンするデータベースを指定します。デフォルトは default
です。
-
--
ARGUMENTS
¶
--
区切り文字に続く引数は、ベースのコマンドライン クライアントに渡されます。たとえば、PostgreSQL では、次のように psql
コマンドの -c
フラグを使うことで、素の SQL クエリを直接実行できます。
$ django-admin dbshell -- -c 'select current_user'
current_user
--------------
postgres
(1 row)
...\> django-admin dbshell -- -c 'select current_user'
current_user
--------------
postgres
(1 row)
MySQL/MariaDB では、次のように mysql
の -e
フラグを使用すると実行できます。
$ django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| djangonaut@localhost |
+----------------------+
...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| djangonaut@localhost |
+----------------------+
diffsettings
¶
-
django-admin diffsettings
¶
現在の設定ファイルと Django のデフォルトの設定 (または他の --default
で指定された設定ファイル) の違いを表示します。
デフォルトに現れない設定には "###"
が続きます。たとえば、デフォルト設定が ROOT_URLCONF
を定義していない場合、diffsettings
の出力内の ROOT_URLCONF
の後には "###"
が表示されます
-
--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
の出力をファイルとして保存すると、 テスト の フィクスチャ や、 初期データ として活用できます。
dumpdata
は、ダンプするレコードを選択するために、モデルのデフォルトのマネージャを使用することに注意してください。カスタム マネージャ をデフォルトのマネージャとして使用していて、利用できるレコードの一部をフィルタリングしている場合、必ずしもすべてのオブジェクトがダンプされるわけではありません。
-
--all
,
-a
¶
レコードをダンプする際に、フィルタリングまたは変更される可能性があるカスタム マネージャーの代わりに、Django のベース マネージャを使用します。
-
--format
FORMAT
¶
出力のシリアライズフォーマットを指定します。デフォルトは JSON です。対応フォーマットは シリアライズフォーマット に一覧があります。
-
--indent
INDENT
¶
出力で使用するインデントのスペースの数を指定します。デフォルトは None
で、全てのデータを1行で表示します。
-
--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
¶
カンマで区切られた主キーのリストで指定されたオブジェクトだけを出力します。これは1つのモデルをダンプするときのみ有効です。デフォルトでは、モデルのすべてのレコードが出力されます。
-
--output
OUTPUT
,
-o
OUTPUT
¶
シリアライズされたデータを書き込むファイルを指定します。デフォルトでは、データは標準出力に出力されます。
このオプションが設定されていて、 --verbosity
が 0 (デフォルト) より大きい場合、ターミナルにプログレスバーが表示されます。
フィクスチャの圧縮¶
出力ファイルは、ファイル名の最後に対応する拡張子をつけることで、 bz2
、gz
、lzma
、xz
のいずれかの形式で圧縮できます。たとえば、データを圧縮された JSON ファイルとして出力するには、次のようにします:
django-admin dumpdata -o mydata.json.gz
flush
¶
-
django-admin flush
¶
データベースからすべてのデータを削除し、同期後のハンドラを再実行します。マイグレーションが適用されたテーブルはクリアされません。
空のデータベースから始めて、すべてのマイグレーションを再実行したい場合は、代わりにデータベースを削除して再作成してから migrate
を実行してください。
-
--noinput
,
--no-input
¶
すべてのユーザープロンプトを表示しません。
-
--database
DATABASE
¶
フラッシュするデータベースを指定します。デフォルトは default
です。
inspectdb
¶
-
django-admin inspectdb [table [table ...]]
¶
NAME
設定で指定されたデータベースのテーブルをイントロスペクトし、 Django モデルモジュール (models.py
ファイル) を標準出力に出力します。
引数にテーブルやビューの名前を渡すことで、検査するテーブルやビューを選択できます。引数を指定しなかった場合、 --include-views
オプションが使用された場合のみ、ビューのモデルが作成されます。PostgreSQL で --include-partitions
オプションが使用された場合、パーティションテーブルのモデルが作成されます。
Django で使いたいレガシーデータベースがある場合に使ってください。このスクリプトはデータベースを検査し、各テーブルのモデルを作成します。
ご想像の通り、作成されたモデルはテーブルのすべてのフィールドに対して属性を持ちます。 inspectdb
はフィールド名の出力において、いくつかの特殊なケースを持つことに注意してください:
- カラムの型をモデルのフィールド型にマッピングできない場合、
inspectdb
はTextField
を使用し、生成されたモデルのフィールドの横に'This field type is a guess.'
という Python のコメントを挿入します。 認識されるフィールドはINSTALLED_APPS
にリストされているアプリに依存します。たとえば、django.contrib.postgres
はいくつかの PostgreSQL 固有のフィールドタイプの認識を追加します。 - データベースのカラム名が Python の予約語 (
pass'
,class'
,for'
など) の場合、inspectdb
は属性名に'_field'
を追加します。 例えば、テーブルに'for'
というカラムがある場合、生成されるモデルはフィールド'for_field'
を持ち、db_column'
属性は'for'
に設定されます。その際、inspectdb
はフィールドの横に'Field renamed because it was a Python reserved word."
という Python コメントを挿入します。
この機能は、決定的なモデル生成としてではなく、ショートカットとして意図されています。 この機能を実行した後、生成されたモデルを自分で見て、カスタマイズしてください。特に、他のモデルを参照するモデルが適切に並ぶように、モデルの順序を並べ替える必要があるでしょう。
Django はモデルフィールドに default
が指定されても、データベースのデフォルト値を作成しません。 同様に、データベースのデフォルト値はモデルフィールドのデフォルト値に変換されませんし、 inspectdb
によって検出されることもありません。
デフォルトでは、 inspectdb
は非管理モデルを作成します。 つまり、モデルの Meta
クラスで managed = False
を指定することで、 Django は各テーブルの作成、変更、削除を管理しないようになります。テーブルのライフサイクルを Django に管理させたい場合は、 managed
オプションを True
に変更する必要があります (あるいは、 True
がデフォルト値なので削除してください)。
データベース固有の注意事項¶
Oracle¶
--include-views
が使用されている場合、モデルはマテリアライズドビューのために作成されます。
PostgreSQL¶
- モデルは外部テーブル用に作成されます。
--include-views
が使用されている場合、モデルはマテリアライズドビューのために作成されます。--include-partitions
が使用されている場合、モデルはパーティションテーブルに対して作成されます。
-
--database
DATABASE
¶
イントロスペクトするデータベースを指定します。デフォルトは default
です。
-
--include-partitions
¶
このオプションを指定すると、パーティション用のモデルも作成されます。
PostgreSQL 向けのサポートのみが実装されています。
-
--include-views
¶
このオプションを指定すると、データベースビュー用のモデルも作成されます。
loaddata
¶
-
django-admin loaddata fixture [fixture ...]
¶
指定された フィクスチャ の内容を検索してデータベースにロードします。
-
--database
DATABASE
¶
データを読み込むデータベースを指定します。デフォルトは default
です。
-
--ignorenonexistent
,
-i
¶
フィクスチャが最初に生成されてから削除された可能性のあるフィールドやモデルを無視します。
-
--app
APP_LABEL
¶
すべてのアプリでフィクスチャを探すのではなく、一つのアプリでフィクスチャを探すように指定します。
-
--format
FORMAT
¶
stdin から読み込む フィクスチャの シリアライズフォーマット (json
や xml
など) を指定します。
-
--exclude
EXCLUDE
,
-e
EXCLUDE
¶
(app_label
または app_label.ModelName
の形で) 指定されたアプリケーションやモデルからのフィクスチャの読み込みを除外します。複数のアプリやモデルを除外するには、このオプションを複数回使います。
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 -
dumpdata
コマンドは loaddata
の入力を生成するために使用できます。
参考
フィクスチャの詳細については フィクスチャ (fixture) トピックを参照してください。
makemessages
¶
-
django-admin makemessages
¶
現在のディレクトリのソースツリー全体を走査し、翻訳が必要な文字列をすべて取り出します。conf/locale ディレクトリ (Django ツリーの場合) か locale ディレクトリ (プロジェクトとアプリケーションの場合) にメッセージファイルを作成 (または更新) します。メッセージファイルを変更した後は、組み込みの gettext サポートを使うために compilemessages
でコンパイルする必要があります。詳しくは 国際化のドキュメント を参照してください。
このコマンドは設定を必要としません。しかし、設定が構成されていない場合、コマンドは MEDIA_ROOT
と STATIC_ROOT
ディレクトリを無視したり、 LOCALE_PATHS
をインクルードしたりすることはできません。
-
--all
,
-a
¶
利用可能な全ての言語に対してメッセージファイルを更新します。
-
--extension
EXTENSIONS
,
-e
EXTENSIONS
¶
検査するファイル拡張子のリストを指定します (デフォルト: html
、txt
、py
、 js
(--domain
が djangojs
の場合)。
使用例:
django-admin makemessages --locale=de --extension xhtml
複数の拡張子はカンマで区切るか、-e
または --extension
を複数回使用してください:
django-admin makemessages --locale=de --extension=html,txt --extension xml
-
--locale
LOCALE
,
-l
LOCALE
¶
処理する場所 (locale) を指定します。
-
--exclude
EXCLUDE
,
-x
EXCLUDE
¶
処理から除外する locale を指定します。提供されなかった場合、どのロケールも除外されません。
使用例:
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
¶
メッセージファイルのドメインを指定します。サポートされているオプションは以下の通りです:
*.py
、*.html
、*.txt
ファイルすべてに対してdjango
(デフォルト)*.js
ファイルに対してdjangojs
-
--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
と同じ)。
gettext
0.19 以降が必要です。
-
--no-obsolete
¶
廃止されたメッセージ文字列を .po
ファイルから削除します。
-
--keep-pot
¶
.po
ファイルが作成される前に生成される一時的な .pot
ファイルを削除しないようにします。最終的な言語ファイルが生成されるのを妨げるようなエラーをデバッグするために有用です。
参考
makemessages
が xgettext
に渡すキーワードをカスタマイズする方法を知りたい場合は、makemessages コマンドをカスタマイズする を参照してください。
makemigrations
¶
-
django-admin makemigrations [app_label [app_label ...]]
¶
検出されたモデルの変更に基づいて、新しいマイグレーションを作成します。マイグレーションおよびそのアプリとの関係は、詳しくは マイグレーションのドキュメント で説明しています。
1つ以上のアプリ名を引数として与えると、作成するマイグレーションを、指定されたアプリとそれに必要な依存関係 (たとえば、外部キーで繋がれた他のテーブルなど) に限定されます。
マイグレーションを migrations
ディレクトリが存在しないアプリに追加するには、makemigrations
にアプリの app_label
を付けて実行します。
-
--noinput
,
--no-input
¶
すべてのユーザープロンプトを抑制します。もし、抑制されたプロンプトが自動的に解決できなかった場合は、エラーコード 3 で終了します。
-
--empty
¶
手動で編集するために、指定されたアプリに対する空のマイグレーションを出力します。このオプションは詳しいユーザーのためのもので、マイグレーションのフォーマット、マイグレーション・オペレーション、およびマイグレーション間の依存関係について十分理解していない限り、使うべきではありません。
-
--dry-run
¶
実際にマイグレーションをディスクには書き込まず、作成される予定のマイグレーションを表示します。このオプションを --verbosity 3
オプションと併用することで、書き込まれる予定のマイグレーションファイルの内容そのものを表示できます。
-
--merge
¶
マイグレーションで発生するコンフリクトの修復を有効にする
-
--name
NAME
,
-n
NAME
¶
生成されたマイグレーションに名前を付けることができます。名前は有効な Python 識別子 でなければなりません。
-
--no-header
¶
Django のバージョンとタイムスタンプヘッダなしでマイグレーションファイルを生成します。
-
--check
¶
マイグレーションを伴わないモデル変更が検出された場合に、 makemigrations
を 0 以外のステータスで終了するようにします。これは --dry-run
を意味します。
-
--scriptable
¶
ログ出力と入力プロンプトを stderr
に流し、生成されたマイグレーションファイルのパスのみを stdout
に書き込みます。
-
--update
¶
モデルの変更を最新のマイグレーションにマージし、その結果生じるオペレーションを最適化します。
更新されたマイグレーションは生成された名前を持ちます。以前の名前を保持するには、--name
を使って設定してください。
migrate
¶
-
django-admin migrate [app_label] [migration_name]
¶
データベースの状態を、現在のモデルとマイグレーションのセットを基づいて同期します。マイグレーションおよびそのアプリとの関係については、詳しくは マイグレーションのドキュメント で説明しています。
このコマンドの動作は、次のように与えられた引数によって変化します。
- 引数なし: 全てのアプリが、それぞれが持つマイグレーションを全て実行します。
<app_label>
: 指定したアプリに最新のマイグレーションまで実行させます。依存関係によっては、他のアプリのマイグレーションも実行される場合もあります<app_label> <migrationname>
: データベーススキーマを、指定した名前のマイグレーションが実行された状態になるようにします。指定したよりも後のマイグレーションは適用されません。指定されたより前のマイグレーションがすでに適用されていた場合など、指定の仕方によってはマイグレーションが実行できない場合があります。アプリに対するすべてのマイグレーションの適用をリセットするには、zero
という名前を指定してください。指定したアプリ名で一意であれば、マイグレーション名のプレフィックス、例えば0001
を使用できます。アプリに適用されたマイグレーションをすべて元に戻すにはzero
という名前を指定してください。
警告
マイグレーションの適用を取り消すと、<app_label>
に関係なく、依存するマイグレーションもすべて取り消されます。どのマイグレーションが取り消されるかを調べるには --plan
を使用してください。
-
--database
DATABASE
¶
マイグレートするデータベースを指定します。デフォルトは default
です。
-
--fake
¶
(上記のルールに従って)ターゲットのマイグレーションまでを適用されたものとしてマークしますが、データベーススキーマを変更するSQLを実際には実行しません。
これは上級ユーザが手動で変更を適用する場合に、現在のマイグレーション状態を直接操作することを想定しています。 --fake
を使用すると、マイグレーションを正しく実行するためにマイグレーション状態テーブルを手動で回復する必要がある状態になる危険性があることに注意してください。
-
--fake-initial
¶
マイグレーションに含まれる全ての CreateModel
オペレーションで作成された全てのモデルの名前を持つデータベーステーブルが既に存在する場合、 Django がアプリの初期マイグレーションをスキップできるようにします。このオプションは、マイグレーションを使用する前のデータベースに対してマイグレーションを初めて実行するときに使用することを想定しています。しかし、このオプションは、テーブル名の一致以外のデータベーススキーマの一致をチェックしないので、既存のスキーマが初期マイグレーションに記録されているものと一致することを確信している場合のみ安全に使用できます。
-
--plan
¶
指定された migrate
コマンドに対して実行されるマイグレーション・オペレーションを表示します。
-
--run-syncdb
¶
マイグレーションせずにアプリ用のテーブルを作成できるようにします。これは推奨されませんが、マイグレーションフレームワークは何百ものモデルがある大規模なプロジェクトでは遅すぎることがあります。
-
--noinput
,
--no-input
¶
すべてのユーザープロンプトを表示しません。プロンプトの例は、古くなったコンテンツタイプの削除に関する質問です。
-
--check
¶
適用されていないマイグレーションが検出された場合に、 migrate
を 0 以外のステータスで終了するようにします。
-
--prune
¶
存在しないマイグレーションを django_migrations
テーブルから削除します。これはスカッシュしたマイグレーションによって置き換えられたマイグレーションファイルが削除された場合に便利です。詳細は マイグレーションのスカッシュ (Squash) を参照してください。
optimizemigration
¶
-
django-admin optimizemigration app_label migration_name
¶
指定されたマイグレーション・オペレーションを最適化し、既存のファイルを上書きします。マイグレーションに手動でコピーしなければならない関数が含まれている場合、このコマンドは _optimized
で終わる新しいマイグレーションファイルを作成し、指定されたマイグレーションを置き換えます。
-
--check
¶
マイグレーションを最適化できる場合に、 optimizemigration
を 0 以外のステータスで終了するようにします。
runserver
¶
-
django-admin runserver [addrport]
¶
ローカルマシンで軽量の開発用ウェブサーバを起動します。デフォルトでは、IPアドレス 127.0.0.1
のポート 8000 で動作します。IPアドレスとポート番号を明示的に渡すこともできます。
このスクリプトを通常の権限を持つユーザ(推奨)で実行した場合、小さいポート番号のポートを起動するためのアクセス権がない可能性があります。小さいポート番号はスーパーユーザ(root)のために予約されています。
このサーバーは WSGI_APPLICATION
設定で指定された WSGI アプリケーションオブジェクトを使用します。
警告
DO NOT USE THIS SERVER IN A PRODUCTION SETTING.
This lightweight development server has not gone through security audits or performance tests, hence is unsuitable for production. Making this server able to handle a production environment is outside the scope of Django.
開発サーバーは必要に応じてリクエストごとにPythonコードを自動的にリロードします。コード変更の効果を得るためにサーバーを再起動する必要はありません。しかしながら、ファイルの追加のようないくつかの行動は再起動をトリガーしません、このような場合はサーバーを再起動する必要があります。
Linux や MacOS を使用していて、 pywatchman と Watchman サービスの両方をインストールしている場合、カーネルシグナルがサーバーの自動再ロードに使用されます(毎秒ファイルの変更タイムスタンプをポーリングするのではなく)。これにより、大規模なプロジェクトでのパフォーマンスが改善され、コード変更後の 応答時間が短縮され、変更検出がより強固になり、消費電力が削減されます。Django は pywatchman
1.2.0 以降をサポートしています。
巨大なディレクトリに多くのファイルが含まれる場合、パフォーマンスの問題を引き起こす可能性があります。
node_modules
のような大きな非 Python ディレクトリを含むプロジェクトで Watchman を使う場合、最適なパフォーマンスのためにこのディレクトリを無視することをお勧めします。この方法については watchman documentation を参照してください。
Watchman のタイムアウト
-
DJANGO_WATCHMAN_TIMEOUT
¶
Watchman クライアントのデフォルトのタイムアウトは 5 秒です。これを変更するには DJANGO_WATCHMAN_TIMEOUT
環境変数を設定します。
サーバを起動したとき、そしてサーバ起動中に Python コードを変更するたびに、システムチェックフレームワークが Django プロジェクト全体に一般的なエラーがないかチェックします (check
コマンドを参照してください)。エラーが見つかった場合、標準出力に出力されます。システムチェックの実行をスキップするには --skip-checks
オプションを使います。
django-admin runserver
を複数回実行することで、異なるポート上であれば、好きなだけ並列でサーバーを実行できます。
デフォルトの IP アドレス 127.0.0.1
は、同じネットワーク上の他のマシンからはアクセスできないことに注意してください。開発用サーバーを他のマシンから見られるようにするには、ネットワーク上の自分のローカル IP アドレス (例 192.168.2.1
) または 0
(0.0.0.0
のショートカット)、 0.0.0.0
、または ::
(IPv6を有効にした場合) を使用します。
ブラケットで囲んだ IPv6 アドレス (例 [200a::1]:8000
) も使用できます。その場合は、IPv6 のサポートが自動的に有効になります。
ホスト名には ASCII 文字のみからなる文字列も使用できます。
staticfiles contrib アプリが有効になっている場合 (新しいプロジェクトのデフォルト)、 runserver
コマンドは独自の runserver コマンドで上書きされます。
サーバの各リクエストとレスポンスのログは django.server ロガーに送られます。
-
--noreload
¶
自動リローダを無効にします。これは、もし特定の Python モジュールが既にメモリに読み込まれている場合、サーバの実行中に行った Python コードの変更は 反映 されないことを意味します。
-
--nothreading
¶
開発サーバーでのスレッドの使用を無効にします。デフォルトではサーバーはマルチスレッドです。
-
--ipv6
,
-6
¶
開発用サーバーで 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
IPv4 アドレスのホスト localhost
上でポート 8000 を使用する場合:
django-admin runserver localhost:8000
IPv6 アドレスのホスト localhost
上でポート 8000 を使用する場合:
django-admin runserver -6 localhost:8000
開発用サーバーで静的 (static) ファイルを配信する¶
デフォルトでは、開発サーバはサイトの静的ファイル (CSS ファイルや画像、 MEDIA_URL
以下にあるものなど) を配信しません。Django が静的メディアを配信するように設定したい場合は、 静的ファイル (画像、JavaScript、CSS など) を管理する を参照してください。
開発中に ASGI サーバーを使う¶
Django の runserver
コマンドは WSGI サーバーを提供します。ASGI で実行するには、 ASGI サーバー を使う必要があります。Django Daphne プロジェクトは、 runserver との統合 を提供しています。
sendtestemail
¶
-
django-admin sendtestemail [email [email ...]]
¶
(Django によるメール送信が動作していることを確認するために)指定した受信者にテストメールを送信します。たとえば以下のようにします:
django-admin sendtestemail foo@example.com bar@example.com
いくつかのオプションがあるので、次のようにそれらを任意に組み合わせて使用できます。
-
--managers
¶
mail_managers()
を使用して MANAGERS
で指定されたメールアドレスにメールします。
-
--admins
¶
mail_admins()
を使用して ADMINS
で指定されたメールアドレスにメールします。
shell
¶
-
django-admin shell
¶
Python のインタラクティブ・インタープリタを開始します。
-
--interface
{ipython,bpython,python}
,
-i
{ipython,bpython,python}
¶
使用するシェルを指定します。デフォルトでは、Django はインストールされている場合には IPython または bpython を使用します。両方インストールされている場合には、次のようにして使いたいシェルを指定してください。
IPython:
django-admin shell -i ipython
bpython:
django-admin shell -i bpython
"リッチな" シェルをインストールしているが、"プレーン" な Python インタプリタを強制的に使いたい場合は、インターフェイス名として python
を次のように使用します:
django-admin shell -i python
-
--no-startup
¶
"プレーン" Python インタプリタのスタートアップスクリプトを読み込まないようにします。デフォルトでは PYTHONSTARTUP
環境変数か ~/.pythonrc.py
スクリプトが指すスクリプトが読み込まれます。
-
--command
COMMAND
,
-c
COMMAND
¶
以下のように、コマンドを文字列で渡して、Django として実行できます:
django-admin shell --command="import django; print(django.__version__)"
標準入力にコードを渡して実行することもできます。たとえば:
$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF
Windowsでは、そのプラットフォームでの select.select()
の実装制限に応じて REPL が出力されます。
showmigrations
¶
-
django-admin showmigrations [app_label [app_label ...]]
¶
プロジェクト内のすべてのマイグレーションを表示します。2つの形式から選択できます:
-
--list
,
-l
¶
Django が知っている全てのアプリ、各アプリで利用可能なマイグレーション、各マイグレーションが適用されているかどうか(マイグレーション名の横に [X]
と表示されます)を一覧表示します。また、 --verbosity
が 2 以上の場合、適用された日時も表示されます。
マイグレーションのないアプリもリストアップされますが、その下に (no migrations)
と表示されます。
これはデフォルトの出力形式です。
-
--plan
,
-p
¶
Django が適用するマイグレーションの計画を表示します。 list
と同様に、適用されたマイグレーションは [X]
でマークされます。また、 --verbosity
が 2 以上の場合、マイグレーションの全ての依存関係も表示されます。
app_label
引数によって出力は制限されますが、提供されたアプリの依存関係も含めることができます。
-
--database
DATABASE
¶
検査するデータベースを指定します。デフォルトは default
です。
sqlflush
¶
-
django-admin sqlflush
¶
flush
コマンドで実行される SQL 文を表示します。
-
--database
DATABASE
¶
SQLを表示するデータベースを指定します。デフォルトは default
です。
sqlmigrate
¶
-
django-admin sqlmigrate app_label migration_name
¶
指定された名前のマイグレーション用の SQL を出力します。これは、制約名の解決に使用するアクティブなデータベース接続を必要とします。つまり、後で適用したいデータベースのコピーに対して SQL を生成する必要があります。
sqlmigrate
は出力に色をつけないことに注意してください。
-
--backwards
¶
マイグレーションの適用を取り消すSQLを生成します。デフォルトでは、マイグレーションを順方向に実行するための SQL が生成されます。
-
--database
DATABASE
¶
SQL を生成するデータベースを指定します。デフォルトは default
です。
sqlsequencereset
¶
-
django-admin sqlsequencereset app_label [app_label ...]
¶
指定されたアプリ名のシーケンスをリセットする SQL 文を出力します。
シーケンスは、自動的にインクリメントされるフィールドの次に利用可能な番号を追跡するために、いくつかのデータベースエンジンで使用されるインデックスです。
このコマンドを使用して、シーケンスが自動的にインクリメントされたフィールドデータと同期していないケースを修正するSQLを生成できます。
-
--database
DATABASE
¶
SQLを表示するデータベースを指定します。デフォルトは default
です。
squashmigrations
¶
-
django-admin squashmigrations app_label [start_migration_name] migration_name
¶
migration_name
までの app_label
のマイグレーションを、可能であればより少ないマイグレーションにスカッシュします。スカッシュされたマイグレーションは、スカッシュされていないマイグレーションと安全に共存できます。詳しくは マイグレーションのスカッシュ (Squash) を参照してください。
start_migration_name
を指定すると、 Django はこのマイグレーションから始まり、このマイグレーションを含むマイグレーションだけを取り込みます。これは RunPython
と django.db.migrations.operations.RunSQL
マイグレーション・オペレーションのスカッシュ制限を緩和するのに役立ちます。
-
--no-optimize
¶
スカッシュされたマイグレーションを生成する際に、オプティマイザを無効にします。デフォルトでは、 Django はマイグレーションする際の処理を最適化し、結果のファイルサイズを小さくしようとします。この処理が失敗したり、正しくないマイグレーションを作成したりする場合は、このオプションを使ってください。最適化は安全であることを意図しているので、その動作について Django バグレポートを提出してください。
-
--noinput
,
--no-input
¶
すべてのユーザープロンプトを表示しません。
-
--squashed-name
SQUASHED_NAME
¶
スカッシュされたマイグレーションの名前を設定します。省略した場合は、最初と最後のマイグレーションの間に _squashed_
を加えた名前になります。
-
--no-header
¶
Django のバージョンとタイムスタンプのヘッダなしで、スカッシュしたマイグレーションファイルを生成します。
startapp
¶
-
django-admin startapp name [directory]
¶
指定されたアプリ名の Django アプリディレクトリ構造を、カレントディレクトリか、指定された保存先に作成します。
デフォルトでは、新しいディレクトリ には models.py
ファイルと他のアプリテンプレートファイルが含まれます。アプリ名だけが与えられた場合、アプリディレクトリは現在の作業ディレクトリに作成されます。
オプションで保存先を指定すると、 Django は新しいディレクトリを作成するのではなく、既存のディレクトリを使用します。現在の作業ディレクトリを表すには "." を使用してください。
例:
django-admin startapp myapp /Users/jezdez/Code/myapp
-
--template
TEMPLATE
¶
カスタムアプリテンプレートファイルを含むディレクトリへのパス、または圧縮されていないアーカイブ (.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/main.zip myapp
-
--extension
EXTENSIONS
,
-e
EXTENSIONS
¶
アプリテンプレート内のどの拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトは py
です。
-
--name
FILES
,
-n
FILES
¶
(--extension
にマッチするものに加えて) アプリテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。
-
--exclude
DIRECTORIES
,
-x
DIRECTORIES
¶
.git
と __pycache__
に加えて、アプリテンプレート内のどのディレクトリを除外するかを指定します。このオプションを指定しない場合、__pycache__
という名前のディレクトリや、.
で始まるディレクトリは除外されます。
マッチする全てのファイルに使用される テンプレートコンテキスト
は以下の通りです:
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 つに、テンプレートレンダリングに関連する特定の機能を説明する docstring が含まれていた場合、間違った結果を生むかもしれません。
この問題を回避するために、テンプレートタグ templatetag
を使ってテンプレートの構文の様々な部分を「エスケープ」することができます。
さらに、パッケージングシステムが無効な *.py
ファイルをバイトコンパイルしようとするのを防ぐと同時に、 Django テンプレート言語構文を含む Python テンプレートファイルを許可するために、 .py-tpl
で終わるテンプレートファイルは .py
にリネームされます。
警告
カスタムアプリ(またはプロジェクト)テンプレートのコンテンツは、使用前に必ず監査されるべきです。 これらのテンプレートは、プロジェクトの一部となるコードを定義しており、これらのコードは、インストールしたアプリや自分で書いたコードと同じくらい信頼されることを意味します。さらに、テンプレートをレンダリングすることは、事実上、提供されたコードを管理コマンドへの入力として実行することにすらなります。Django のテンプレート言語は、システムへの広いアクセスを提供する可能性がありますので、使うカスタムテンプレートが信頼に値するものであることを確認してくだ さい。
startproject
¶
-
django-admin startproject name [directory]
¶
指定されたプロジェクト名の Django プロジェクトディレクトリ構造を、カレントディレクトリか指定された保存先に作成します。
デフォルトでは、 新しいディレクトリ には manage.py
とプロジェクトパッケージ (settings.py
と他のファイルを含む) があります。
プロジェクト名だけを指定した場合、プロジェクトディレクトリとプロジェクトパッケージは <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
にマッチするものに加えて) プロジェクトテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。
-
--exclude
DIRECTORIES
,
-x
DIRECTORIES
¶
.git
と __pycache__
に加えて、プロジェクトテンプレート内のどのディレクトリを除外するかを指定します。このオプションを指定しない場合、__pycache__
という名前のディレクトリや、.
で始まるディレクトリは除外されます。
使用される テンプレートコンテキスト
は以下の通りです:
startproject
コマンドに渡されたオプション (コマンドでサポートされているオプションに限る)project_name
-- コマンドに渡されたプロジェクト名project_directory
-- 新規作成されたプロジェクトのフルパスsecret_key
--SECRET_KEY
設定用のランダムなキー。docs_version
-- ドキュメントのバージョン:'dev'
または1.x'
django_version
-- Django のバージョン、例えば'2.0.3'
。
startapp
で説明した レンダリングに関する警告 と 信頼されたコードに関する警告 も参照してください。
test
¶
-
django-admin test [test_label [test_label ...]]
¶
インストールされている全てのアプリのテストを実行します。詳しくは Django におけるテスト を参照してください。
-
--failfast
¶
テストが失敗したら直ちにテストの実行を停止し、失敗を報告します。
-
--testrunner
TESTRUNNER
¶
テストの実行に使われるテストランナークラスを制御します。この値は TEST_RUNNER
設定によって提供される値を上書きします。
-
--noinput
,
--no-input
¶
すべてのユーザープロンプトを表示しません。典型的なプロンプトは、既存のテストデータベースの削除に関する警告です。
テストランナーのオプション¶
test
コマンドは指定された --testrunner
の代わりにオプションを受け取ります。これらはデフォルトのテストランナーである DiscoverRunner
のオプションです。
-
--keepdb
¶
テスト実行の間、テストデータベースを保持します。これには、作成と破棄の両方のアクションを省略できるという利点があり、 特に大規模なテストスイートにおけるテストの実行時間を大幅に短縮できます。テストデータベースが存在しない場合は、最初の実行時に作成され、それ以降の実行時に保存されます。MIGRATE
テスト設定が False
でない限り、テストスイートを実行する前に、未適用のマイグレーションもテストデータベースに適用されます。
-
--shuffle
[SEED]
¶
テストを実行する前に、テストの順番をランダムにします。これは、適切に分離されていないテストの検出に役立ちます。このオプションで生成されるテストの順番は、 与えられた整数シードの決定論的な関数です。シードが渡されない場合は、ランダムにシードが選ばれてコンソールに出力されます。特定のテスト順序を繰り返すには、シードを渡します。このオプションで生成されるテスト順序は Django の テスト順序における保証 を保持します。また、テストはテストケースクラスごとにグループ化されます。
シャッフルされた順序は、分離の問題を絞り込む際に有用な特別な一貫性を持っています。つまり、シードを指定してテストのサブセットを実行する場合、新しい順序はより小さなセットに制限されつつ、元のシャッフル順序を維持します。同様に、シードを同じに保ちながらテストを追加すると、元のテストの順序は新しい順序でも同じままです。
-
--reverse
,
-r
¶
テストケースを逆の実行順序で並べ替えます。これは適切に分離されていないテストの副作用をデバッグする際に役立つかもしれません。 テストクラス によるグループ化は、このオプションを使用しても保持されます。 --shuffle
と組み合わせて使用することで、特定のシードの順番を逆にできます。
-
--debug-mode
¶
テストを実行する前に DEBUG
設定を True
に設定します。これはテストの失敗のトラブルシューティングに役立ちます。
-
--debug-sql
,
-d
¶
失敗したテストの SQL ロギング を有効にします。もし --verbosity
が 2
なら、パスしたテストのクエリも出力されます。
-
--parallel
[N]
¶
-
DJANGO_TEST_PROCESSES
¶
別々の並列プロセスでテストを実行します。現代のプロセッサは複数のコアを備えているため、これによってテストの実行速度を大幅に向上させることができます。
値を指定せずに --parallel
を使用した場合、または値 auto
を指定した場合、 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 は例外のトレースバックを表示できないかもしれません。これはデバッグを困難にします。この問題に遭遇した場合は、並列化せずに該当するテストを実行して、失敗のトレースバックを確認してください。
これは既知の制限です。これは、プロセス間でオブジェクトを交換するためにオブジェクトをシリアライズする必要があることから生じます。詳しくは What can be pickled and unpickled? を参照してください。
-
--tag
TAGS
¶
指定したタグ でマークされたテストのみを実行します。test --exclude-tag
と組み合わせて複数回指定できます。
ロードに失敗したテストは常にマッチしたとみなされます。
-
--exclude-tag
EXCLUDE_TAGS
¶
指定したタグ でマークされたテストを除外します。test --tag
と組み合わせて複数回指定できます。
-
-k
TEST_NAME_PATTERNS
¶
unittest の -k オプション
と同じように、テスト名のパターンにマッチするテストメソッドとクラスを実行します。複数回指定できます。
-
--pdb
¶
テストのエラーや失敗のたびに pdb
デバッガを起動します。インストールされている場合は、代わりに ipdb
が使用されます。
-
--buffer
,
-b
¶
unittest の --buffer オプション
と同じように、テストに合格した出力 (stdout
と stderr
) を破棄します。
-
--no-faulthandler
¶
Django はテストの開始時に faulthandler.enable()
を自動的に呼び出します。これにより、インタプリタがクラッシュした場合にトレースバックを表示します。この動作を無効にするには --no-faulthandler
を渡してください。
-
--timing
¶
データベースのセットアップや総実行時間などのタイミングを出力します。
-
--durations
N
¶
最も遅い N 個のテストケースを表示します(N=0 の場合はすべて)。
Python 3.12 以降が必要です
この機能は Python 3.12 以降でのみ利用可能です。
testserver
¶
-
django-admin testserver [fixture [fixture ...]]
¶
(runserver
のように) 与えられたフィクスチャのデータを使って Django 開発サーバを起動します。
たとえばこのコマンドは、:
django-admin testserver mydata.json
... 以下のステップを実行します:
- test データベース で説明されているように、テスト用データベースを作成します。
- 与えられたフィクスチャからフィクスチャデータをテストデータベースに投入します。(フィクスチャの詳細については、上記の
loaddata
のドキュメントを参照してください)。 - Django 開発サーバを実行します (
runserver
のように)。本番用データベースの代わりに、新しく作成したテスト用データベースを指定します。
これはいろいろな面で便利です:
- ユニットテスト を書くとき、フィクスチャデータを使ってビューがどのように動作するか、
testserver
を使ってウェブブラウザでビューと手動でやりとりできます。 - Django アプリケーションを開発していて、対話したいデータベースの "まっさらな" コピーがあるとします。データベースを フィクスチャ にダンプし (上で説明した
dumpdata
コマンドを使います)、そのデータを使ってtestserver
で Web アプリケーションを実行します。この方法では、どんなデータの変更もテスト用のデータベースに対してだけ行われるため、柔軟にデータを変更できます。
このサーバは Python のソースコードの変更を (runserver
のように) 自動的に検出することは しない ことに注意してください。しかし、テンプレートの変更は検出します。
-
--addrport
ADDRPORT
¶
デフォルトの 127.0.0.1:8000
とは異なるポート、または IP アドレスとポートを指定します。この値は runserver
コマンドの引数と全く同じフォーマットで、全く同じ機能を果たします。
例:
ポート7000で fixture1
と fixture2
を使ってテストサーバを動かすには、以下のようにします:
django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000
(上の2つは等価です。オプションがフィクスチャの引数の前でも後でも問題ないことを示すために、この2つを紹介しています)
1.2.3.4:7000 で test
フィクスチャを使って実行するには、下記のようにします:
django-admin testserver --addrport 1.2.3.4:7000 test
-
--noinput
,
--no-input
¶
すべてのユーザープロンプトを表示しません。典型的なプロンプトは、既存のテストデータベースの削除に関する警告です。
アプリケーションが提供するコマンド¶
いくつかのコマンドは、それを 実装した django.contrib
アプリケーションが 有効に
なっていないと利用できません。この節では、それらをアプリケーションごとに分類して説明します。
django.contrib.auth
¶
changepassword
¶
-
django-admin changepassword [<username>]
¶
このコマンドは Django の 認証システム (django.contrib.auth
) がインストールされている場合のみ利用できます。
ユーザのパスワードを変更できます。指定されたユーザの新しいパスワードを2回入力するよう求められます。入力が同じであれば、これが直ちに新しいパスワードになります。ユーザを指定しなかった場合、コマンドはユーザ名が現在のユーザと一致するパスワードを変更しようとします。
-
--database
DATABASE
¶
ユーザーをクエリするデータベースを指定します。デフォルトは default
です。
使用例:
django-admin changepassword ringo
createsuperuser
¶
-
django-admin createsuperuser
¶
-
DJANGO_SUPERUSER_PASSWORD
¶
このコマンドは Django の 認証システム (django.contrib.auth
) がインストールされている場合のみ利用できます。
superuser アカウント (すべての権限を持ったユーザー) を作成します。このコマンドは、最初に superuser アカウントを作成する場合や、サイトの superuser アカウントをプログラムから自動生成する必要がある場合に便利です。
対話的に実行すると、このコマンドは新しいスーパーユーザアカウントのパスワードを要求します。非対話的に実行する場合、 DJANGO_SUPERUSER_PASSWORD
環境変数を設定することでパスワードを設定できます。そうでない場合、パスワードは設定されず、スーパーユーザーアカウントはパスワードが手動で設定されるまでログインできません。
非インタラクティブモードでは、 USERNAME_FIELD
と必須フィールド (REQUIRED_FIELDS
にリストされています) はコマンドライン引数で上書きされない限り、環境変数 DJANGO_SUPERUSER_<uppercase_field_name>
にフォールバックします。例えば、 email
フィールドを指定するには、環境変数 DJANGO_SUPERUSER_EMAIL
を使用します。
-
--noinput
,
--no-input
¶
すべてのユーザープロンプトを表示しません。もし、抑制されたプロンプトが自動的に解決できなかった場合は、エラーコード 1 で終了します。
-
--username
USERNAME
¶
-
--email
EMAIL
¶
新しいアカウントのユーザー名とメールアドレスはコマンドラインの --username
と --email
引数で指定できます。これらのどちらかが与えられない場合、 createsuperuser
は対話的に実行する際にその入力を要求します。
-
--database
DATABASE
¶
スーパーユーザ・オブジェクトを保存するデータベースを指定します。
データの入力とバリデーションをカスタマイズしたい場合は、管理コマンドをサブクラス化して get_input_data()
をオーバーライドします。既存の実装やメソッドのパラメータの詳細についてはソースコードを参照してください。たとえば、REQUIRED_FIELDS
に ForeignKey
があり、既存のインスタンスの主キーを入力する代わりにインスタンスを作成できるようにしたい場合に便利です。
django.contrib.contenttypes
¶
remove_stale_contenttypes
¶
-
django-admin remove_stale_contenttypes
¶
このコマンドは Django の contenttypes アプリ (django.contrib.contenttypes
) がインストールされている場合のみ利用できます。
(削除されたモデルの)古くなったコンテンツタイプをデータベースから削除します。削除されたコンテンツタイプに依存しているオブジェクトも削除されます。削除されたオブジェクトのリストが表示された後、削除を続行できます。
-
--database
DATABASE
¶
使用するデータベースを指定します。デフォルトは default
です。
-
--include-stale-apps
¶
INSTALLED_APPS
から削除された、以前にインストールされたアプリのものを含む、古くなったコンテンツタイプを削除します。デフォルトは False
です。
django.contrib.gis
¶
ogrinspect
¶
このコマンドは、GeoDjango (django.contrib.gis
) がインストールされている場合のみ使用できます。
GeoDjango のドキュメントの description
を参照してください。
django.contrib.sessions
¶
django.contrib.staticfiles
¶
collectstatic
¶
このコマンドは static files アプリケーション (django.contrib.staticfiles
) がインストールされている場合のみ使用できます。
staticfiles ドキュメントの description
を参照してください。
findstatic
¶
このコマンドは static files アプリケーション (django.contrib.staticfiles
) がインストールされている場合のみ使用できます。
staticfiles ドキュメントの description
を参照してください。
デフォルトのオプション¶
コマンドによっては独自のカスタムオプションを使用できるものもありますが、どのコマンドでもデフォルトでは以下のオプションが使用できます:
-
--pythonpath
PYTHONPATH
¶
与えられたファイルシステムのパスを Python sys.path
モジュール属性に追加します。これが指定されていない場合、django-admin
は PYTHONPATH
環境変数を使用します。
このオプションは manage.py
では不要です。Python のパスの設定は manage.py
が行ってくれるからです。
使用例:
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
が発生するとエラーメッセージを表示し、それ以外の例外が発生すると完全なスタックトレースを表示します。
このオプションは runserver
では無視されます。
使用例:
django-admin migrate --traceback
-
--verbosity
{0,1,2,3}
,
-v
{0,1,2,3}
¶
コマンドがコンソールに表示する通知とデバッグ情報の量を指定します。
0
は出力なしを意味します。1
は通常の出力を意味します(デフォルト)。2
は詳細な出力を意味します。3
は 非常に 詳細な出力を意味します。
このオプションは runserver
では無視されます。
使用例:
django-admin migrate --verbosity 2
-
--no-color
¶
カラー表示されたコマンドの出力を無効にします。一部のコマンドは、出力をカラー表示するようにフォーマットされます。たとえば、エラーは赤色でコンソールに表示され、SQL文はシンタックスハイライトされます。
使用例:
django-admin runserver --no-color
-
--force-color
¶
シンタックスカラーリング で説明されているように、コマンドの出力が無効になる場合でも出力のカラー表示を強制します。例えば、色付きの出力を別のコマンドにパイプしたい場合などに使用します。
-
--skip-checks
¶
コマンドを実行する前のシステムチェックをスキップします。このオプションは requires_system_checks
コマンド属性が空のリストやタプルでない場合にだけ有効です。
使用例:
django-admin migrate --skip-checks
追加の便利機能¶
シンタックスカラーリング¶
-
DJANGO_COLORS
¶
dango-admin
/ manage.py
コマンドは、ターミナルが ANSI カラー出力をサポートしている場合、色分けされた出力を使用します。 --force-color
オプションが使用されていない限り、コマンドの出力を他のプログラムにパイプしてもカラー出力は使用されません。
Windows でのサポート¶
Windows 10 では、 Windows Terminal アプリケーション、 VS Code 、および PowerShell (仮想ターミナル処理が有効になっている場合) では色付きの出力が可能で、デフォルトでサポートされています。
Windows では、レガシーの cmd.exe
ネイティブコンソールは ANSI エスケープシーケンスをサポートしていないため、デフォルトではカラー出力ができません。この場合、2つのサードパーティライブラリのどちらかが必要になります:
colorama は、ANSI カラーコードを Windows API 呼び出しに変換する Python パッケージです。Django のコマンドはこのパッケージの存在を検出し、Unix ベースのプラット フォームと同じように、このパッケージのサービスを利用して出力に色をつけます。
colorama
は pip でインストールできます:...\> py -m pip install "colorama >= 0.4.6"
ANSICON をインストールします。これは、
cmd.exe
が ANSI カラーコードを処理できるようにするサードパーティツールです。Django のコマンドはこのツールの存在を検出し、Unix ベースのプラットフォームと同じように、このツールのサービスを利用して出力に色をつけます。
ターミナルカラーをサポートしているが、Django がサポートしていることを自動的に検出しない Windows の他のモダンなターミナル環境では、 ANSICON="on"
という適切な環境変数を設定することで、 ANSICON
のインストールを「偽装」することができます。
カラーをカスタマイズする¶
シンタックスハイライトに使う色はカスタマイズできます。Django には 3 つのカラーパレットが同梱されています:
dark
, 黒い背景に白いテキストを表示する端末に適しています。これはデフォルトのパレットです。light
, これは白い背景に黒いテキストを表示する端末に適しています。nocolor
, これはシンタックスハイライトを無効にします。
パレットを選択するには DJANGO_COLORS
環境変数を設定して使用したいパレットを指定します。例えば、UnixやOS/XのBASHシェルで 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 Informational サーバーレスポンス。http_success
- 2XX HTTP Success サーバーレスポンス。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
- マイグレーション管理コマンドの見出し。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
は色を変更するオプションの一つです。複数の色の指定はセミコロンで区切ります。たとえば以下のようにします:
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
これを指定すると、エラーは青地に黄色の点滅で表示され、通知はマゼンタで表示されます。それ以外の色の役割には色を付けません。
色はベースパレットを拡張して指定することもできます。色指定にパレット名を入れると、そのパレットが意味するすべての色が読み込まれます。つまり:
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
これを指定すると、light カラーパレットのすべての色の使用が指定されますが、error と notice の色は指定どおりにオーバーライドされます。
Bash による補完¶
Bash シェルを使用している場合は、Django bash 補完スクリプトのインストールを検討してください。スクリプトは Django のソース配布元の extras/django_bash_completion にあります。このスクリプトを使うと、django-admin
と manage.py
コマンドで tab キーによる補完が有効になります。使い方を説明すると、
- まず、
django-admin
とタイプします。 - [TAB] キーをクリックし、利用できるオプション一覧を表示します。
sql
とタイプし、[TAB] キーを押すと、名前がsql
で始まるオプション一覧が表示されます。
独自のカスタムアクションを追加したい場合は、カスタム django-admin コマンドの作り方 を読んでください。
Black フォーマッタ¶
startproject
, startapp
, optimizemigration
, makemigrations
, squashmigrations
によって作成された Python ファイルは、 black
コマンドが PATH
にあれば、それを使ってフォーマットされます。
もし black
がグローバルにインストールされているが、現在のプロジェクトで使用したくない場合は、 PATH
を明示的に設定できます:
PATH=path/to/venv/bin django-admin makemigrations
stdout
を使用するコマンドでは、必要に応じて出力を black
にパイプできます:
django-admin inspectdb | black -
コードから管理コマンドを実行する¶
-
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)
コマンドオプションの中には、 djangoo-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)