| revision-up-to: | 8961 (1.0) |
|---|
django-admin.py は Django の管理タスクを行うためのコマンドライン ユーティリティです。このドキュメントでは django-admin.py の全ての 機能について説明します。
また、各 Django プロジェクトには manage.py が自動的に生成されます。 manage.py は django-admin.py に対する薄いラッパで、 django-admin.py に仕事を引き渡す前に以下の二つの処理を行います:
Django を setup.py ユーティリティでインストールしていれば、 django-admin.py スクリプトはシステムパス上にあるはずです。システム パス上にない場合、 Python インストールディレクトリ上の site-packages/django/bin を探せば見つかるでしょう。 /usr/local/bin のようなパス上のどこかにシンボリックリンクを張って おくように勧めます。
Windows を使っていて、シンボリックリンクを張れない場合には、パスの通った場 所に django-admin.py をコピーするか、 PATH の設定値を ( マイコンピュータ(右クリック) - プロパティ - 詳細設定 - 環境変数 - システム環境変数 で) django-admin.py のインストールされ ている場所を指すように変更してください。
一般論として、一つの Django プロジェクトだけで作業しているなら、 manage.py を使う方が簡単といえるでしょう。 django-admin.py と DJANGO_SETTINGS_MODULE や --settings コマンドラインオプション を使えば、複数の Django 設定ファイルを切替えて操作できます。
このドキュメント内でのコマンドライン例では、一貫して django-admin.py を 使っていますが、実際には manage.py を使ってもかまいません。
``django-admin.py <subcommand> [options]``
``manage.py <subcommand> [options]``
subcommand には、このドキュメントで挙げているいずれかのサブコマンド を指定します。 options は省略可能で、このドキュメントで挙げている ゼロ個から複数個の利用可能なオプションをサブコマンドに与えます。
Django 0.96では、 django-admin.py --help を実行すると、利用できる全ての サブコマンドとオプションの詳細なリストの入ったヘルプメッセージを出力します。
開発版のDjangoでは、 django-admin.py --help を実行すると、利用できる全ての サブコマンドを出力します。 django-admin.py help <subcommand> を実行すると 与えられたサブコマンドで利用できるオプションの詳細なリストを出力します。
ほとんどのサブコマンドは appname のリストを引数にとります。 appname はモデルの入ったパッケージの名前です。例えば INSTALLED_APPS に mysite.blog を追加している場合、このアプリケーションの appname は blog です。
cron によるジョブとして実行したり、直接実行したりして、データベースから 古いデータ (現時点では、有効期限の切れたセッションのみ) を消去します。
makemessages で作成した .po ファイルをコンパイルして、組み込みの gettext サポートで使えるようにします。詳しくは 国際化 を参照し てください。
処理したいロケールを指定するには --locale または -l オプションを使 います。指定しなければ、全てのロケールを処理します。
使い方:
django-admin.py compilemessages --locale=br_PT
データベースキャッシュバックエンドで使うための、 tablename という 名前のキャッシュテーブルを生成します。詳しくは Django のキャッシュフレームワーク を参照し てください。
スーパユーザアカウント (全てのパーミッションを保有するユーザ) を作成します。 初期スーパユーザを syncdb の実行時以外の場所で作成したい場合や、プログ ラム上でスーパユーザアカウントを生成したい場合に便利です。
対話的に実行すると、 django-admin.py コマンドはスーパユーザアカウントの パスワードを入力するよう促します。非対話的に実行した場合、パスワードは設定 されず、パスワードを手動で設定するまで、作成されたスーパユーザはログインで きません。
新たに作成するアカウントのユーザ名と e-mail アドレスは、それぞれ コマンドラインの --username および --email 引数で指定できます。 どちらの引数も指定しなければ、 createsuperuser は対話モードでの実行時に 入力を促します。
このコマンドは Django の 認証システム (django.contrib.auth) がインストールされている時にのみ利用可能です。
DATABASE_ENGINE 設定に指定されたデータベースエンジンに対し、 DATABASE_USER および DATABASE_PASSWORD 等の設定に従ってコマンドライ ンクライアントを起動します。
このコマンドはプログラムが PATH 上にあると想定しているので、単純に プログラム名で呼び出したとき (psql, mysql, sqlite3) に見つかる プログラムを使います。プログラムの場所を手動で指定する方法はありません。
現在の設定ファイルと Django のデフォルト設定との差分を表示します。
デフォルト設定にない設定の末尾には "###" を追加します。例えば、 デフォルト設定には ROOT_URLCONF 変数がないので、 diffsettings の出力中では ROOT_URLCONF の末尾に "###" が付きます。
デフォルト設定の完全なリストを見たければ、 django/conf/global_settings.py にある Django のデフォルト設定を参照して ください。
指定したアプリケーション (複数指定可) に関係した全てのデータをデータベース から取り出し、標準出力に出力します。
アプリケーション名を指定しなかった場合、インストール済みのアプリケーション 全てのデータをダンプします。
dumpdata の出力は loaddata の入力に使えます。
dumpdata は、ダンプするレコードを取り出すときに、モデルのデフォルトマネ ジャを使います。デフォルトマネジャに カスタムマネジャ を使っていて、カスタムマネジャ内 でレコードの一部をフィルタしていると、一部のオブジェクトがダンプされなくな るので注意してください。
出力から、特定のアプリケーションに関するコンテンツを除外します。例えば、 auth アプリケーションのコンテンツを出力から除外したければ、以下のように 実行します:
django-admin.py dumpdata --exclude=auth
複数のアプリケーションを除外したければ、複数回 --exclude ディレクティブ を使います:
django-admin.py dumpdata --exclude=auth --exclude=contenttype
データベースを syncdb 直後の状態に戻します。全てのデータがデータベースから 除去され、同期直後に呼び出される全てのハンドラが再度実行されます。また、 initial_data フィクスチャも再インストールされます。
以前は、このコマンドはデータベース上のテーブルを (INSTALLED_APPS に登録 されているモデルに関係しているかどうかに関わらず) 全て 消去していました。
1.0 からは、 INSTALLED_APPS で有効化しているモデルのテーブルだけを消去 します。
DATABASE_NAME 設定で指定されたデータベース上のテーブルに対するイントロ スペクションを行い、Django モデルモジュール (models.py) を標準出力に出 力します。
古いデータベースを持っていて、それを Django で使いたい場合に使ってくだ さい。スクリプトはデータベースを調べ、データベース内の各テーブルに対す るモデルを生成します。
想像の通り、生成されるモデルは、テーブルの各フィールド名に対応する属性 を持ちます。 inspectdb はフィールド名の出力に際して以下のようないく つかの特殊なケースを持っているので注意して下さい:
この機能は単に手間を省くためのもので、しっかりしたモデル生成を行うため のものではありません。実行した後に生成されたモデルを自分で確かめてカス タマイズを行うことになるでしょう。具体的には、他のモデルを参照しているよう なモデルが正しい順番で並ぶようにします。
PostgreSQL や MySQL を使っている場合、イントロスペクションで主キーを自動的 に決定し、必要な場所に primary_key=True を追加します。
inspectdb は PostgreSQL, MySQL および SQLite で動作します。外部キー の検出は PostgreSQL と一部の MySQL テーブル形式でのみ有効です。
名前付きのフィクスチャを探し、その中身をデータベースにロードします。
フィクスチャ (fixture) とは、データベースに入れるデータをシリアライズして 格納したファイル群を指します。各フィクスチャファイルには固有の名前を付けら れますが、ある名前のフィクスチャを複数のディレクトリに入れても構いませんし、 複数のアプリケーション内に配置してもかまいません。
Django は以下の 3 種類の場所からフィクスチャを探します:
Django は上記の場所に見つかった全てのフィクスチャファイルの中から、指定した フィクスチャ名と一致するファイルをロードします。
フィクスチャ名にファイル拡張子を指定すると、指定した型のフィクスチャだけが ロードされます。例えば:
django-admin.py loaddata mydata.json
のようにすると、 mydata という名前の JSON フィクスチャだけがロードされ ます。フィクスチャの拡張子は、 (json や xml のように) シリアライザ の登録名に対応していなければなりません。
拡張子を省略すると、 Django は全ての形式にフィクスチャを対象にフィクスチャ ファイルを検索します。例えば:
django-admin.py loaddata mydata
のようにすると、 mydata という名前の全てのフィクスチャを探します。フィ クスチャディレクトリに mudata.json という名前のファイルがあれば、 JSON 形式のフィクスチャとしてロードされます。同じ名前で別のフィクスチャ形式のも のが見つかった場合 (例えば、 mydata.json と mydata.xml が同じディレ クトリ下にあった場合)、フィクスチャのインストールは中止され、それまでに loaddata によってロードされたデータは全てデータベースから削除されます。
フィクスチャの名前にはディレクトリ名を入れても構いません。ディレクトリ部分 を指定すると、各検索パスに追加されます。例えば:
django-admin.py loaddata foo/bar/mydata.json
とすると、インストール済みの各アプリケーションのディレクトリ <appname> について <appname>/fixtures/foo/bar/mydata.json を、 FIXTURE_DIRS の各ディレクトリ <dirname> について <dirname>/foo/bar/mydata.json を、そして相対パス foo/bar/mydata.json を探します。
フィクスチャファイルの処理順は決まっていませんが、全てのフィクスチャのイン ストールは単一のトランザクションで行われるため、あるフィクスチャが別のフィ クスチャに対する参照を持っていてもかまいません。データベースバックエンドが 行レベルの制約 (row-level constraint) をサポートしているばあい、制約はトラ ンザクションの最後にチェックされます。
dumpdata コマンドを使うと、 loaddata の入力データを生成できます。
MySQL とフィクスチャ
残念ながら、MySQL は Django のフィクスチャに関する全ての機能を利用でき るわけではありません。 MyISAM を使っている場合、 MySQL はトランザクショ ンや制約をサポートしていないので、複数のフィクスチャファイルに対するロー ルバックを行えず、フィクスチャデータの検証も行えません。一方、 InnoDB を使っている場合、データファイル間で前方参照を行えません。 MySQL は行制 約のチェックをトランザクションコミット直前まで遅延するためのメカニズム を備えていないからです。
django-admin.py のメッセージの通知やデバッグ情報のコンソールへの出力量を 指定するには --verbosity を使います。
使用例:
django-admin.py loaddata --verbosity=2
現在のディレクトリ以下にあるソースツリー全体を走査して、翻訳対象にマークさ れている文字列全てを取り出します。django のソースツリー上で行った場合には conf/locale 下に、プロジェクトやアプリケーションのソースツリー上で行っ た場合には locale 下にメッセージファイルを作成します。メッセージファイ ルに変更があった場合、 compilemessages でファイルをコンパイルして、組み 込みの gettext サポートで利用できるようにしてください。詳しくは i18n のドキュメント を参照してください。
メッセージを取り出す対象に含めるファイルの拡張子を指定するには --extension または -e オプションを使います(デフォルトは ".html" で す)。
使い方:
django-admin.py makemessages --locale=de --extension xhtml
複数の拡張子を指定するには、カンマで区切るか、 --extension や -e を複数使います:
django-admin.py makemessages --locale=de --extension=html,txt --extension xml
処理したいロケールを指定するには --locale または -l オプションを使 います。
使い方:
django-admin.py makemessages --locale=br_PT
メッセージファイルのドメインを変更するには --domain または -d オプ ションを使ってください。
現在サポートしているのは、以下のドメインです:
django-admin.py の通知情報やデバッグ情報のコンソールへの出力量を指定する には --verbosity または -v を使います。
使い方:
django-admin.py makemessages --verbosity=2
指定した appname に対して sqlreset と同じ操作を実行します。
ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には --noinput オプションを使います。対話を必要とせずに django-admin.py を実行する自動化されたスクリプトで役に立ちます。
FastCGI プロトコルをサポートする Web サーバ向けの一連の FastCGI プロセス群 を起動します。詳しくは FastCGI による運用 を参照してください。 Python の FastCGI インタフェースモジュールである flup が必要です。
ローカルマシン上に軽量な開発用ウェブサーバを立ち上げます。デフォルトでは、 サーバは IP アドレス 127.0.0.1、ポート番号 8000 で動作します。 IP アドレス やポート番号は明示的に指定できます。
このスクリプトを通常ユーザの権限下で実行した場合 (そうするように勧めます)、 ポート番号を低い値にできないかもしれません。値の低いポート番号はスーパユー ザ (root) 用に予約されているからです。
開発用サーバをプロダクションサーバとして使ってはなりません。 開発用サー バはセキュリティ検査もパフォーマンステストも行われていません(我々が目指して いるのは Web フレームワークの開発であり、このサーバを改良して運用環境でも利 用できるようにするのは Django プロジェクトの目的とするところではありません。)
開発サーバはリクエストを受け付ける度に、必要に応じて自動的に Python コード をリロードします。このため、コードの変更を反映させるためにいちいちサーバを 際起動しなくてもよくなっています。
サーバの起動時や、サーバの稼働中に Python コードを変更した場合、開発用サー バはインストールされている全てのモデルを自動的に検証します (後述の validate オプションを参照してください)。検証時にエラーが見つかった場合、 エラーは標準出力に出力されますが、サーバは停止しません。
ポート番号を別々にしているかぎりいくつでもサーバを起動できます。 django-admin.py runserver を複数回起動するだけです。
デフォルトの IP アドレスである 127.0.0.1 は、ネットワーク上の他のマシンから は利用できません。開発サーバをネットワーク上の他のマシンから見えるようにす るには、サーバホスト固有の IP アドレス (例えば 192.168.2.1) または 0.0.0.0 を使って下さい。
Django 管理インタフェース用の CSS や JavaScript ファイルを探す場所を Django に 教えるには --adminmedia オプションを使います。通常、これらのファイルは Django のソースツリーから探索されて配信されるようになっていますが、自作のサイト 用に変更を加えた CSS や JavaScript を指定したい場合には、このオプションを使いま す。
使用例:
django-admin.py runserver --adminmedia=/tmp/new-admin-style/
自動リロード機能の使用を無効にするには --noreload オプションを使います。 これが意味するところは、サーバの稼働中にいかなる Python コードの変更も検知 せず 既にメモリ上に読み込まれている Python モジュールが利用されます。
使用例:
django-admin.py runserver --noreload
IP アドレス 127.0.0.1、ポート番号 8000:
django-admin.py runserver
IP アドレス 1.2.3.4、ポート番号 8000:
django-admin.py runserver 1.2.3.4:8000
IP アドレス 127.0.0.1、ポート番号 7000:
django-admin.py runserver 7000
IP アドレス 1.2.3.4、ポート番号 7000:
django-admin.py runserver 1.2.3.4:7000
デフォルトでは、開発用サーバはサイト用の静的ファイル (CSSファイル、画像、 MEDIA_URL 下のファイルなど) を全く提供しません。 Django に静的メディ アを提供させたければ、 静的なファイルの提供方法 を参照してください。
開発サーバの起動中にコードのオートリロードが起きるのを止めたければ、以下の ように --noreload オプションを使ってください:
django-admin.py runserver --noreload
Python の対話インタプリタを起動します。
IPython がインストールされている場合、Django は IPython を使おうとします。 IPython がインストールされていて、かつ「普通の」インタプリタを使いたいのな ら、以下のように --plain オプションを使って下さい:
django-admin.py shell --plain
指定した appname の CREATE TABLE SQL 文を出力します。
指定した appname の CREATE TABLE および初期カスタム SQL の発行、データ入力 のための SQL 文を出力します。
初期カスタム SQL の指定方法は sqlcustom の説明を参照してください。
指定した appname の DROP TABLE SQL 文を出力します。
指定した appname のカスタム SQL 文を出力します。
このコマンドは、指定した各アプリケーションのモデルについて、 <appname> をアプリケーションの名前、 <modelname> をモデルの名前を全て小文字にした 文字列として、 <appname>/sql/<modelname>.sql という名前のファイルを探し ます。例えば、 news というアプリケーションで Story というモデルが定 義されていれば、 sqlcustom は news/sql/story.sql というファイルを探 して読みだし、その内容をこのコマンドの出力の末尾に追加します。
各 SQL ファイルには、有効な SQL を入れることになっています。 SQL ファイルの 内容は、モデルのテーブル生成文を全て実行した後に、データベースに直接パイプ されます。テーブルに対して変更を加えたり、 SQL 関数をデータベースに組み込む には、この SQL フックを使ってください。
指定したアプリケーションに対する CREATE INDEX SQL 文を出力します。
指定した appname に対する DROP TABLE SQL 文を出力し、 その後で CREATE TABLE SQL 文を出力します。
指定した appname のシークエンスをリセットするためのSQL 文を出力します。
詳しくは http://simon.incutio.com/archive/2004/04/21/postgres を参照し てください。
現在のディレクトリに、 appname に指定した名前の Django アプリケーショ ンディレクトリ階層を作成します。
現在のディレクトリに、 projectname に指定した名前の Django プロジェク トディレクトリ階層を作成します。
--settings オプションを指定して django-admin.py を呼び出したときや、 環境変数 DJANGO_SETTINGS_MODULE が指定されていると、このコマンドを使え ません。 startproject を使いたければ、 --settings オプションを外し、 DJANGO_SETTINGS_MODULE を unset してください。
INSTALLED_APPS に登録されており、まだテーブルを作成していないアプリケー ション全てのテーブルを作成します。
このコマンドは、新たなアプリケーションをプロジェクトに追加し、データベース にインストールしたい場合に使って下さい。アプリケーションには、 Django に付 属しているアプリケーションで、デフォルトで INSTALLED_APPS に入っている ものも含みます。新たなプロジェクトを開始する際には、このコマンドを実行して デフォルトのアプリケーションをインストールする必要があります。
syncdb は既存のテーブルを置き換えません
syncdb は、インストールされていないモデルのテーブルしか作成しません。 すでにインストールされているモデルクラスに変更を行っても、それに合わせる ように ALTER TABLE を発行することは 決してありません 。モデルクラ スやデータベーススキーマに対する変更には、何らかの形であいまいな部分があ るものです。そのあいまいな部分に対して、 Django どのように変更を適用すべ きか正しく判断せねばならないとすれば、変更の過程で重要なデータが失われる というリスクが生まれてしまいます。
モデルに変更を適用した後、変更に合わせてデータベーステーブルも置き換えた いのなら、 sql コマンドを使って新たな SQL を出力し、既存のテーブルス キーマと比較して、手動で変更を適用してください。
django.contrib.auth アプリケーションをインストールした場合には、 syncdb はスーパユーザを作成するか尋ねます。
syncdb はまた、 initial_data という名前で、適切な拡張子 (json や xml など) のフィクスチャを探してインストールします。フィクスチャデー タファイルの詳細は loaddata のドキュメントを参照してください。
django-admin.py の通知情報やデバッグ情報のコンソールへの出力量を指定する には --verbosity を使います。
使用例:
django-admin.py syncdb --verbosity=2
ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には --noinput オプションを使います。対話を必要とせずに django-admin.py を実行する自動化されたスクリプトで役に立ちます。
インストールされている全てのモデルについてテストを実行します。 詳しくは Django アプリケーションのテスト を参照して ください。
ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には --noinput オプションを使います。対話を必要とせずに django-admin.py を実行する自動化されたスクリプトで役に立ちます。
django-admin.py の通知情報やデバッグ情報のコンソールへの出力量を指定する には --verbosity を使います。
使用例:
django-admin.py test --verbosity=2
指定したフィクスチャを使って、 (runserver と同様に) 開発用サーバを起動 します。
例えば、次のコマンド:
django-admin.py testserver mydata.json
を実行すると、以下のようなステップを実行します:
testserver が便利な局面はいくつかあります:
runserver は動作中に Python のソースコード上に加えられた変更を自動的に 検出しますが、 testserver は検出しません。ただし、テンプレートへの変更 は検出します。
IP アドレスやポート番号を 127.0.0.1:8000 から変更するには、 --addrport を使います。この値は、 runserver サブコマンドの引数と同じ形式で指定し、 意味も同じです。
テストサーバをポート 7000 で起動し、 fixture1 および fixture2 のテ ストを実施するには、以下のようにします:
django-admin.py testserver --addrport 7000 fixture1 fixture2 django-admin.py testserver fixture1 fixture2 --addrport 7000
(上の二つのコマンドは互いに等価です。オプションはフィクスチャを指定するため の引数の前にきても後ろに来てもかまいません。)
test フィクスチャを 1.2.3.4:7000 で実行するには、以下のようにします:
django-admin.py testserver --addrport 1.2.3.4:7000 test
django-admin.py の通知情報やデバッグ情報のコンソールへの出力量を指定する には --verbosity を使います。
使用例:
django-admin.py testserver --verbosity=2
インストールされている (INSTALLED_APPS に登録されている) 全てのモ デルを検証 (validate) し、エラーがあれば標準出力に出力します。
各々のサブコマンドの独自のオプションの他に、以下の共通のオプションがありま す:
使用例:
django-admin.py syncdb --pythonpath='/home/djangoprojects/myproject'
指定したファイルシステムパスを Python の import 検索パス に追加 します。このオプションを指定しない場合、 django-admin.py は環境変 数 PYTHONPATH を使います。
manage.py は Python パスをきちんと設定してくれるので、このオプション は必要ありません。
使用例:
django-admin.py init --settings=mysite.settings
管理対象のプロジェクトの設定モジュールを明示的に指定します。設定モジュー ルは Python のパッケージ表現構文、すなわち "mysite.settings" のような形式で 指定します。このオプションを指定しない場合、 django-admin.py は環境変数 DJANGO_SETTINGS_MODULE を使います。
manage.py はデフォルトで現在のプロジェクトの settings.py を使うので、 通常はこのオプションは必要ありません。
使用例:
django-admin.py syncdb --traceback
デフォルトでは、 django-admin.py はエラーが起きるたびに簡単なエラーメッ セージを表示します。 --traceback を指定すると django-admin.py は 例外が送出された際に完全なスタックトレースを出力します。
SQL 文を標準出力に出力する django-admin.py / manage.py コマンドは、 端末が ANSI カラー出力をサポートする場合にはコードを色づけして表示します。 ただし、出力を別のプログラムにパイプしている場合には色づけを行いません。
bash シェルを使っているのなら、 Django の bash 補完スクリプトのインストール を検討してみてください。スクリプトは Django 配布物の extras/django_bash_completion にあります。 bash 補完機能を使うと、 django-admin.py および manage.py コマンドをタブ補完できるようになり ます。例えば:
アクションを自作するには、 アクションを自作する を参照し てください。
Aug 31, 2012