django-adminおよびmanage.py
django-admin
は、管理タスク用のDjangoのコマンドラインユーティリティです。 このドキュメントでは、実行できるすべての概要を説明します。
さらに、manage.py
は各Djangoプロジェクトで自動的に作成されます。 django-admin
と同じことを行いますが、プロジェクトのsettings.py
ファイルを指すように、 DJANGO_SETTINGS_MODULE 環境変数も設定します。
pip
を介してDjangoをインストールした場合は、django-admin
スクリプトがシステムパス上にあるはずです。 パス上にない場合は、Pythonインストール内のsite-packages/django/bin
にあります。 /usr/local/bin
など、パス上のどこかからシンボリックリンクすることを検討してください。
シンボリックリンク機能を利用できないWindowsユーザーの場合は、django-admin.exe
を既存のパス上の場所にコピーするか、PATH
設定(Settings - Control Panel - System - Advanced - Environment...
の下)を編集してポイントすることができます。そのインストール場所。
一般に、単一の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 で説明されているスキーマに従います。
1.4.dev17026
1.4a1
1.4
デバッグ出力の表示
--verbosity
を使用して、django-admin
がコンソールに出力する通知およびデバッグ情報の量を指定します。
使用可能なコマンド
check
システムチェックフレームワークを使用して、Djangoプロジェクト全体に一般的な問題がないか検査します。
デフォルトでは、すべてのアプリがチェックされます。 引数としてアプリラベルのリストを提供することで、アプリのサブセットを確認できます。
django-admin check auth admin myapp
アプリを指定しない場合は、すべてのアプリがチェックされます。
システムチェックフレームワークは、タグで分類されたさまざまなタイプのチェックを実行します。 これらのタグを使用して、実行されるチェックを特定のカテゴリのチェックのみに制限できます。 たとえば、モデルと互換性チェックのみを実行するには、次のコマンドを実行します。
django-admin check --tag models --tag compatibility
使用可能なすべてのタグを一覧表示します。
展開設定にのみ関連するいくつかの追加チェックをアクティブにします。
このオプションはローカル開発環境で使用できますが、ローカル開発設定モジュールには多くの実稼働設定がない可能性があるため、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
バージョン3.0の新機能。
指定された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
です。
ノート
: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(デフォルト)より大きい場合、端末にプログレスバーが表示されます。
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
を使用すると、パーティションテーブルのモデルが作成されます。
バージョン2.2で変更:外部テーブルとマテリアライズドビューのサポートが追加されました。
イントロスペクトするデータベースを指定します。 デフォルトはdefault
です。
バージョン2.2の新機能。
このオプションを指定すると、パーティションのモデルも作成されます。
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
形式で圧縮できます。 例えば:
django-admin loaddata mydata.json
mydata.json
、mydata.json.zip
、mydata.json.gz
、またはmydata.json.bz2
のいずれかを検索します。 zip圧縮されたアーカイブに含まれる最初のファイルが使用されます。
同じ名前でフィクスチャタイプが異なる2つのフィクスチャが検出された場合(たとえば、mydata.json
とmydata.xml.gz
が同じフィクスチャディレクトリで見つかった場合)、フィクスチャのインストールは中止され、 loaddata
の呼び出しでインストールされたデータはデータベースから削除されます。
MyISAMとフィクスチャを備えたMySQL
MySQLのMyISAMストレージエンジンはトランザクションまたは制約をサポートしていないため、MyISAMを使用する場合、フィクスチャデータの検証、または複数のトランザクションファイルが見つかった場合のロールバックは取得されません。
データベース固有のフィクスチャ
マルチデータベース設定を使用している場合は、あるデータベースにロードしたいが別のデータベースにはロードしたくないフィクスチャデータがある可能性があります。 この状況では、フィクスチャの名前にデータベース識別子を追加できます。
たとえば、: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 識別子である必要があります。
バージョン2.2の新機能。
Djangoのバージョンとタイムスタンプヘッダーなしで移行ファイルを生成します。
移行なしのモデル変更が検出された場合、makemigrations
をゼロ以外のステータスで終了させます。
migrate
データベースの状態を現在のモデルと移行のセットと同期します。 移行、アプリとの関係などについては、移行ドキュメントで詳しく説明されています。
このコマンドの動作は、提供された引数に応じて変わります。
- 引数なし:すべてのアプリですべての移行が実行されます。
<app_label>
:指定されたアプリでは、最新の移行までの移行が実行されます。 これには、依存関係のために、他のアプリの移行の実行も含まれる場合があります。<app_label> <migrationname>
:データベーススキーマを、指定された移行が適用される状態にしますが、同じアプリでのそれ以降の移行は適用されません。 名前付き移行を過ぎて以前に移行したことがある場合、これには適用されない移行が含まれる場合があります。 移行名のプレフィックスを使用できます。例:0001
、指定されたアプリ名で一意である限り。zero
という名前を使用して、完全に元に戻します。 アプリに適用されたすべての移行を元に戻します。
警告
移行を適用解除すると、<app_label>
に関係なく、依存するすべての移行も適用されなくなります。 --plan
を使用して、どの移行が適用されないかを確認できます。
移行するデータベースを指定します。 デフォルトはdefault
です。
データベーススキーマを変更するために実際にSQLを実行せずに、(上記のルールに従って)ターゲットへの移行を適用済みとしてマークします。
これは、上級ユーザーが手動で変更を適用している場合に、現在の移行状態を直接操作することを目的としています。 --fake
を使用すると、移行状態テーブルが移行を正しく実行するために手動リカバリが必要な状態になるリスクがあることに注意してください。
その移行ですべての CreateModel 操作によって作成されたすべてのモデルの名前を持つすべてのデータベーステーブルがすでに存在する場合、Djangoがアプリの初期移行をスキップできるようにします。 このオプションは、移行の使用がすでに存在するデータベースに対して最初に移行を実行するときに使用することを目的としています。 ただし、このオプションは、一致するテーブル名以外に一致するデータベーススキーマをチェックしないため、既存のスキーマが最初の移行で記録されたものと一致することが確実な場合にのみ安全に使用できます。
バージョン2.2の新機能。
指定された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を使用する場合、最適なパフォーマンスを得るためにこのディレクトリを無視することをお勧めします。 これを行う方法については、ウォッチマンのドキュメントを参照してください。
警備員のタイムアウト
Watchman
クライアントのデフォルトのタイムアウトは5秒です。 DJANGO_WATCHMAN_TIMEOUT
環境変数を設定することで変更できます。
バージョン2.2で変更:ウォッチマンのサポートがpyinotify
のサポートに置き換わりました。
サーバーを起動すると、サーバーの実行中に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)
が印刷されています。
これがデフォルトの出力フォーマットです。
バージョン3.0で変更:詳細度2以上で適用された日時の出力が追加されました。
移行を適用するためにDjangoが従う移行計画を示します。 --list
と同様に、適用された移行は[X]
でマークされます。 --verbosity
が2以上の場合、移行のすべての依存関係も表示されます。
app_label
の引数は出力を制限しますが、提供されたアプリの依存関係も含まれる場合があります。
調べるデータベースを指定します。 デフォルトは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_
があります。
バージョン2.2の新機能。
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
バージョン3.0での変更: XZアーカイブ(.tar.xz
、.txz
)およびLZMAアーカイブ(.tar.lzma
、.tlz
)のサポートが追加されました。
アプリテンプレートのどのファイル拡張子をテンプレートエンジンでレンダリングするかを指定します。 デフォルトは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: `DEBUG` 設定をTrue
に設定します。 これは、テストの失敗のトラブルシューティングに役立つ場合があります。
失敗したテストに対して SQLロギングを有効にします。 --verbosity
が2
の場合、合格したテストのクエリも出力されます。
別々の並列プロセスでテストを実行します。 最新のプロセッサには複数のコアがあるため、これによりテストの実行が大幅に高速化されます。
デフォルトでは、--parallel
は、multiprocessing.cpu_count()
に従って、コアごとに1つのプロセスを実行します。 オプションの値として指定することにより、プロセスの数を調整できます。 --parallel=4
、またはDJANGO_TEST_PROCESSES
環境変数を設定します。
Djangoは、テストケース(unittest.TestCase
サブクラス)をサブプロセスに配布します。 構成されたプロセスよりもテストケースが少ない場合、Djangoはそれに応じてプロセスの数を減らします。
各プロセスは独自のデータベースを取得します。 異なるテストケースが同じリソースにアクセスしないようにする必要があります。 たとえば、ファイルシステムにアクセスするテストケースは、独自に使用するための一時ディレクトリを作成する必要があります。
このオプションでは、トレースバックを正しく表示するために、サードパーティの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
と組み合わせることができます。
バージョン3.0の新機能。
unittest's -k option
と同じ方法で、テスト名のパターンに一致するテストメソッドとクラスを実行します。 複数回指定できます。
Python3.7以降
この機能は、Python3.7以降でのみ使用できます。
バージョン3.0の新機能。
テストエラーまたは失敗のたびにpdb
デバッガーを生成します。 インストールしている場合は、代わりにipdb
が使用されます。
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の認証システム(django.contrib.auth
)がインストールされている場合にのみ使用できます。
スーパーユーザーアカウント(すべての権限を持つユーザー)を作成します。 これは、最初のスーパーユーザーアカウントを作成する必要がある場合、またはサイトのスーパーユーザーアカウントをプログラムで生成する必要がある場合に役立ちます。
インタラクティブに実行すると、このコマンドは新しいスーパーユーザーアカウントのパスワードの入力を求めます。 非対話的に実行する場合は、DJANGO_SUPERUSER_PASSWORD
環境変数を設定してパスワードを入力できます。 それ以外の場合、パスワードは設定されず、パスワードが手動で設定されるまでスーパーユーザーアカウントはログインできません。
非対話型モードでは、 USERNAME_FIELD および必須フィールド( REQUIRED_FIELDS にリストされている)は、コマンドライン引数によってオーバーライドされない限り、DJANGO_SUPERUSER_<uppercase_field_name>
環境変数にフォールバックします。 たとえば、email
フィールドを提供するには、DJANGO_SUPERUSER_EMAIL
環境変数を使用できます。
バージョン3.0で変更: DJANGO_SUPERUSER_PASSWORD
およびDJANGO_SUPERUSER_<uppercase_field_name>
環境変数の使用のサポートが追加されました。
すべてのユーザープロンプトを抑制します。 抑制されたプロンプトを自動的に解決できない場合、コマンドはエラーコード1で終了します。
新しいアカウントのユーザー名と電子メールアドレスは、コマンドラインの--username
および--email
引数を使用して指定できます。 これらのいずれかが提供されていない場合、createsuperuser
はインタラクティブに実行するときにそれを要求します。
スーパーユーザーオブジェクトが保存されるデータベースを指定します。
データの入力と検証をカスタマイズする場合は、管理コマンドをサブクラス化し、get_input_data()
をオーバーライドできます。 既存の実装とメソッドのパラメータの詳細については、ソースコードを参照してください。 たとえば、 REQUIRED_FIELDS にForeignKey
があり、既存のインスタンスの主キーを入力する代わりにインスタンスの作成を許可したい場合に便利です。
django.contrib.contenttypes
remove_stale_contenttypes
このコマンドは、Djangoの contenttypes app ( django.contrib.contenttypes )がインストールされている場合にのみ使用できます。
データベース内の古いコンテンツタイプを(削除されたモデルから)削除します。 削除されたコンテンツタイプに依存するオブジェクトもすべて削除されます。 削除を続行してもよいことを確認する前に、削除されたオブジェクトのリストが表示されます。
使用するデータベースを指定します。 デフォルトはdefault
です。
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
が発生したときにエラーメッセージを表示し、その他の例外については完全なスタックトレースを表示します。
使用例:
django-admin migrate --traceback
コマンドがコンソールに出力する通知およびデバッグ情報の量を指定します。
0
は出力がないことを意味します。1
は通常の出力を意味します(デフォルト)。2
は、詳細な出力を意味します。3
は、非常に詳細な出力を意味します。
使用例:
django-admin migrate --verbosity 2
色付きのコマンド出力を無効にします。 一部のコマンドは、出力を色付けするようにフォーマットします。 たとえば、エラーは赤でコンソールに出力され、SQLステートメントは構文が強調表示されます。
使用例:
django-admin runserver --no-color
バージョン2.2の新機能。
構文の色付けで説明されているように、コマンド出力が無効になる場合は、コマンド出力の色付けを強制します。 たとえば、色付きの出力を別のコマンドにパイプしたい場合があります。
バージョン3.0の新機能。
コマンドを実行する前に、実行中のシステムチェックをスキップします。 このオプションは、 require_system_checks コマンド属性がTrue
に設定されている場合にのみ使用できます。
使用例:
django-admin migrate --skip-checks
余分な素敵さ
構文の色付け
django-admin
/ manage.py
コマンドは、端末がANSI色の出力をサポートしている場合、かなり色分けされた出力を使用します。 --force-color
オプションが使用されていない限り、コマンドの出力を別のプログラムにパイプする場合、カラーコードは使用されません。
Windowsでは、ネイティブコンソールはANSIエスケープシーケンスをサポートしていないため、デフォルトではカラー出力はありません。 ただし、 ANSICON サードパーティツールをインストールすることはできます。Djangoコマンドはその存在を検出し、そのサービスを利用して、Unixベースのプラットフォームと同じように出力に色を付けます。
構文の強調表示に使用される色はカスタマイズできます。 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)