.. _ref-django-admin: ============================ django-admin.py と manage.py ============================ :revision-up-to: 11321 (1.1) unfinished ``django-admin.py`` は Django の管理タスクを行うためのコマンドライン ユーティリティです。このドキュメントでは ``django-admin.py`` の全ての 機能について説明します。 また、各 Django プロジェクトには ``manage.py`` が自動的に生成されます。 ``manage.py`` は ``django-admin.py`` に対する薄いラッパで、 ``django-admin.py`` に仕事を引き渡す前に以下の二つの処理を行います: * プロジェクトのパッケージを ``sys.path`` に追加します。 * :envvar:`DJANGO_SETTINGS_MODULE` 環境変数がプロジェクトの ``settings.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`` を使ってもかまいません。 使い方 ====== .. code-block:: bash django-admin.py [options] manage.py [options] ``subcommand`` には、このドキュメントで挙げているいずれかのサブコマンド を指定します。 ``options`` は省略可能で、このドキュメントで挙げている ゼロ個から複数個の利用可能なオプションをサブコマンドに与えます。 ランタイムヘルプを取得する -------------------------- .. django-admin-option:: --help ``django-admin.py help`` を実行すると、利用できる全てのサブコマンドを出力し ます。 ``django-admin.py help `` を実行すると、指定のサブコマン ドで利用できるオプションの詳細なリストを出力します。 アプリケーションの名前 ---------------------- 多くのサブコマンドが ``appname`` のリストを引数にとります。 ``appname`` はモデルの入ったパッケージの名前です。例えば ``INSTALLED_APPS`` に ``mysite.blog`` を追加している場合、このアプリケーションの ``appname`` は ``blog`` です。 バージョンを表示する -------------------- .. django-admin-option:: --version ``django-admin.py --version`` を実行すると、使用しているDjangoのバージョンを表示します。 表示例:: 0.95 0.96 0.97-pre-SVN-6069 デバッグ出力を表示する ----------------------- .. django-admin-option:: --verbosity ``django-admin.py`` の通知情報やデバッグ情報のコンソールへの出力量を指定する には ``--verbosity`` を使います。 * ``0`` だと、何も出力しません。 * ``1`` だと、通常の出力 (デフォルト) です。 * ``2`` だと、詳細に出力します。 利用可能なサブコマンド ====================== cleanup ------- .. versionadded:: 1.0 ``cron`` によるジョブとして実行したり、直接実行したりして、データベースから 古いデータ (現時点では、有効期限の切れたセッションのみ) を消去します。 compilemessages --------------- .. versionadded:: 1.0 1.0 以前は "bin/compile-message.py" コマンドでした。 ``makemessages`` で作成した .po ファイルをコンパイルして、組み込みの gettext サポートで使えるようにします。詳しくは :ref:`topics-i18n` を参照し てください。 --locale ~~~~~~~~ 処理したいロケールを指定するには ``--locale`` または ``-l`` オプションを使 います。指定しなければ、全てのロケールを処理します。 使い方:: django-admin.py compilemessages --locale=br_PT createcachetable ----------------- .. django-admin:: createcachetable データベースキャッシュバックエンドで使うための、 ``tablename`` という 名前のキャッシュテーブルを生成します。詳しくは :ref:`topics-cache` を参照し てください。 createsuperuser --------------- .. django-admin:: createsuperuser .. versionadded:: 1.0 スーパユーザアカウント (全てのパーミッションを保有するユーザ) を作成します。 初期スーパユーザを ``syncdb`` の実行時以外の場所で作成したい場合や、プログ ラム上でスーパユーザアカウントを生成したい場合に便利です。 対話的に実行すると、 ``django-admin.py`` コマンドはスーパユーザアカウントの パスワードを入力するよう促します。非対話的に実行した場合、パスワードは設定 されず、パスワードを手動で設定するまで、作成されたスーパユーザはログインで きません。 .. django-admin-option:: --username .. django-admin-option:: --email 新たに作成するアカウントのユーザ名と e-mail アドレスは、それぞれ コマンドラインの ``--username`` および ``--email`` 引数で指定できます。 どちらの引数も指定しなければ、 ``createsuperuser`` は対話モードでの実行時に 入力を促します。 このコマンドは Django の :ref:`認証システム ` (``django.contrib.auth``) がインストールされている時にのみ利用可能です。 dbshell ------- .. django-admin:: dbshell ``DATABASE_ENGINE`` 設定に指定されたデータベースエンジンに対し、 ``DATABASE_USER`` および ``DATABASE_PASSWORD`` 等の設定に従ってコマンドライ ンクライアントを起動します。 * PostgreSQL の場合には ``psql`` を実行します。 * MySQL の場合には ``mysql`` を実行します。 * SQLite の場合には ``sqlite3`` を実行します。 このコマンドはプログラムが ``PATH`` 上にあると想定しているので、単純に プログラム名で呼び出したとき (``psql``, ``mysql``, ``sqlite3``) に見つかる プログラムを使います。プログラムの場所を手動で指定する方法はありません。 diffsettings ------------ .. django-admin:: diffsettings 現在の設定ファイルと Django のデフォルト設定との差分を表示します。 デフォルト設定にない設定の末尾には ``"###"`` を追加します。例えば、 デフォルト設定には ``ROOT_URLCONF`` 変数がないので、 ``diffsettings`` の出力中では ``ROOT_URLCONF`` の末尾に ``"###"`` が付きます。 デフォルト設定の完全なリストを見たければ、 ``django/conf/global_settings.py`` にある Django のデフォルト設定を参照して ください。 dumpdata -------- .. django-admin:: dumpdata 指定したアプリケーション (複数指定可) に関係した全てのデータをデータベース から取り出し、標準出力に出力します。 アプリケーション名を指定しなかった場合、インストール済みのアプリケーション 全てのデータをダンプします。 ``dumpdata`` の出力は ``loaddata`` の入力に使えます。 ``dumpdata`` は、ダンプするレコードを取り出すときに、モデルのデフォルトマネ ジャを使います。デフォルトマネジャに :ref:`カスタムマネジャ ` を使っていて、カスタムマネジャ内 でレコードの一部をフィルタしていると、一部のオブジェクトがダンプされなくな るので注意してください。 .. django-admin-option:: --exclude .. versionadded:: 1.0 出力から、特定のアプリケーションに関するコンテンツを除外します。例えば、 ``auth`` アプリケーションのコンテンツを出力から除外したければ、以下のように 実行します:: django-admin.py dumpdata --exclude=auth 複数のアプリケーションを除外したければ、複数回 ``--exclude`` ディレクティブ を使います:: django-admin.py dumpdata --exclude=auth --exclude=contenttype .. django-admin-option:: --format デフォルトでは、 ``dumpdata`` は JSON 形式でデータを出力しますが、 ``--format`` オプションを使って別の形式を指定することもできます。現在サ ポートしているフォーマットは :ref:`serialization-formats` に列挙されて います。 .. django-admin-option:: --indent デフォルトでは、 ``dumpdata`` はすべてのデータを1行で出力します。これは 人間にとって読みやすくありません。出力を整形するためのインデント幅のス ペース数の指定に ``--indent`` オプションを使えます。 .. versionadded:: 1.1 In addition to specifying application names, you can provide a list of individual models, in the form of ``appname.Model``. If you specify a model name to ``dumpdata``, the dumped output will be restricted to that model, rather than the entire application. You can also mix application names and model names. flush ----- .. django-admin:: flush データベースを syncdb 直後の状態に戻します。全てのデータがデータベースから 除去され、同期直後に呼び出される全てのハンドラが再度実行されます。また、 ``initial_data`` フィクスチャも再インストールされます。 .. django-admin-option:: --noinput ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制 には ``--noinput`` オプションを使います。対話を必要とせずに ``django-admin.py`` を実行する自動化されたスクリプトで役に立ちます。 inspectdb ---------- .. django-admin:: inspectdb ``DATABASE_NAME`` 設定で指定されたデータベース上のテーブルに対するイントロ スペクションを行い、Django モデルモジュール (``models.py``) を標準出力に出 力します。 古いデータベースを持っていて、それを Django で使いたい場合に使ってくだ さい。スクリプトはデータベースを調べ、データベース内の各テーブルに対す るモデルを生成します。 想像の通り、生成されるモデルは、テーブルの各フィールド名に対応する属性 を持ちます。 ``inspectdb`` はフィールド名の出力に際して以下のようないく つかの特殊なケースを持っているので注意して下さい: * ``inspectdb`` があるカラムの型に対して適切なモデルのフィールド型 を決定できなかった場合、 ``TextField`` が使われ、生成されたモデ ルの該当するフィールド名の次の行に、 ``'This field type is a guess.'`` というコメントが入ります。 * データベースのカラム名が Python の予約語 (``'pass'``, ``'class'``, ``'for'`` など) の場合、 ``inspectdb`` は属性名の後ろに ``'_field'`` を追加します。例えば、テーブルに ``'for'`` という名前のフィールドがあ れば、生成されるモデルは ``'for_field'`` という名前のフィールドを持ち、 このフィールドの ``db_column`` 属性は ``'for'`` になります。 ``inspectdb`` はフィールド名の次の行に、 ``'Field renamed because it was a Python reserved word.'`` というコメ ントを追加します。 この機能は単に手間を省くためのもので、しっかりしたモデル生成を行うため のものではありません。実行した後に生成されたモデルを自分で確かめてカス タマイズを行うことになるでしょう。具体的には、他のモデルを参照しているよう なモデルが正しい順番で並ぶようにします。 PostgreSQL や MySQL を使っている場合、イントロスペクションで主キーを自動的 に決定し、必要な場所に ``primary_key=True`` を追加します。 ``inspectdb`` は PostgreSQL, MySQL および SQLite で動作します。外部キー の検出は PostgreSQL と一部の MySQL テーブル形式でのみ有効です。 loaddata ------------------------------ 名前付きのフィクスチャ (fixture) を探し、その中身をデータベースにロードします。 フィクスチャとは ~~~~~~~~~~~~~~~~~ *フィクスチャ* とは、データベースに入れるデータをシリアライズして 格納したファイル群を指します。各フィクスチャファイルには固有の名前を付けら れますが、ある名前のフィクスチャを複数のディレクトリに入れても構いませんし、 複数のアプリケーション内に配置してもかまいません。 Django は以下の 3 種類の場所からフィクスチャを探します: 1. インストール済みの各アプリケーションの ``fixtures`` ディレクトリ 2. ``FIXTURE_DIRS`` 設定に指定したディレクトリ 3. fixture に直接指定したパス Django は上記の場所に見つかった全てのフィクスチャファイルの中から、指定した フィクスチャ名と一致するファイルをロードします。 フィクスチャ名にファイル拡張子を指定すると、指定した型のフィクスチャだけが ロードされます。例えば:: django-admin.py loaddata mydata.json のようにすると、 ``mydata`` という名前の JSON フィクスチャだけがロードされ ます。フィクスチャの拡張子は、 (``json`` や ``xml`` のように) :ref:`シリアライザ ` の登録名に対応していなければな りません。 拡張子を省略すると、 Django は全ての形式にフィクスチャを対象にフィクスチャ ファイルを検索します。例えば:: django-admin.py loaddata mydata のようにすると、 ``mydata`` という名前の全てのフィクスチャを探します。フィ クスチャディレクトリに ``mudata.json`` という名前のファイルがあれば、 JSON 形式のフィクスチャとしてロードされます。 フィクスチャの名前にはディレクトリ名を入れても構いません。ディレクトリ部分 を指定すると、各検索パスに追加されます。例えば:: django-admin.py loaddata foo/bar/mydata.json とすると、インストール済みの各アプリケーションのディレクトリ ```` について ``/fixtures/foo/bar/mydata.json`` を、 ``FIXTURE_DIRS`` の各ディレクトリ ```` について ``/foo/bar/mydata.json`` を、そして相対パス ``foo/bar/mydata.json`` を探します。 フィクスチャファイルを処理する際、データはデータベースにそのまま保存され、 モデルごとに定義した ``save`` メソッドや ``pre_save`` シグナルは呼び出され ません。 フィクスチャファイルの処理順は決まっていませんが、全てのフィクスチャのイン ストールは単一のトランザクションで行われるため、あるフィクスチャが別のフィ クスチャに対する参照を持っていてもかまいません。データベースバックエンドが 行レベルの制約 (row-level constraint) をサポートしているばあい、制約はトラ ンザクションの最後にチェックされます。 ``dumpdata`` コマンドを使うと、 ``loaddata`` の入力データを生成できます。 Compressed fixtures ~~~~~~~~~~~~~~~~~~~ Fixtures may be compressed in ``zip``, ``gz``, or ``bz2`` format. For example:: django-admin.py loaddata mydata.json would look for any of ``mydata.json``, ``mydata.json.zip``, ``mydata.json.gz``, or ``mydata.json.bz2``. The first file contained within a zip-compressed archive is used. 同じ名前で別のフィクスチャ形式のものが見つかった場合 (例えば、 ``mydata.json`` と ``mydata.xml.gz`` が同じディレクトリ下にあった場合)、フィ クスチャのインストールは中止され、それまでに ``loaddata`` によってロードさ れたデータは全てデータベースから削除されます。 .. admonition:: MySQL とフィクスチャ 残念ながら、MySQL は Django のフィクスチャに関する全ての機能を利用でき るわけではありません。 MyISAM を使っている場合、 MySQL はトランザクショ ンや制約をサポートしていないので、複数のフィクスチャファイルに対するロー ルバックを行えず、フィクスチャデータの検証も行えません。一方、 InnoDB を使っている場合、データファイル間で前方参照を行えません。 MySQL は行制 約のチェックをトランザクションコミット直前まで遅延するためのメカニズム を備えていないからです。 makemessages ------------ .. versionadded:: 1.0 1.0 より前のバージョンでは、 ``bin/make-messages.py`` コマンドでした。 現在のディレクトリ以下にあるソースツリー全体を走査して、翻訳対象にマークさ れている文字列全てを取り出します。django のソースツリー上で行った場合には ``conf/locale`` 下に、プロジェクトやアプリケーションのソースツリー上で行っ た場合には ``locale`` 下にメッセージファイルを作成します。メッセージファイ ルに変更があった場合、 ``compilemessages`` でファイルをコンパイルして、組み 込みの gettext サポートで利用できるようにしてください。詳しくは :ref:`i18n のドキュメント ` を参照してください。 --all ~~~~~ 全ての言語のメッセージファイルを更新するには ``--all`` または ``-a`` を使っ てください。 使い方:: django-admin.py makemessages --all --extension ~~~~~~~~~~~ メッセージを取り出す対象に含めるファイルの拡張子を指定するには ``--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 ~~~~~~~~ 処理したいロケールを指定するには ``--locale`` または ``-l`` オプションを使 います。 使い方:: django-admin.py makemessages --locale=br_PT --domain ~~~~~~~~ メッセージファイルのドメインを変更するには ``--domain`` または ``-d`` オプ ションを使ってください。 現在サポートしているのは、以下のドメインです: * ``django``: ``*.py`` ファイルと ``*.html`` ファイル (デフォルト) * ``djangojs``: ``*.js`` ファイル .. _django-admin-reset: reset --------------------------- 指定した appname に対して ``sqlreset`` と同じ操作を実行します。 --noinput ~~~~~~~~~ ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には ``--noinput`` オプションを使います。対話を必要とせずに ``django-admin.py`` を実行する自動化されたスクリプトで役に立ちます。 runfcgi [options] ----------------- FastCGI プロトコルをサポートする Web サーバ向けの一連の FastCGI プロセス群 を起動します。詳しくは :ref:`FastCGI による運用 ` を参照してください。 Python の FastCGI インタフェースモジュールである `flup`_ が必要です。 .. _flup: http://www.saddi.com/software/flup/ runserver --------- .. django-admin:: runserver [port or ipaddr:port] ローカルマシン上に軽量な開発用ウェブサーバを立ち上げます。デフォルトでは、 サーバは 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-admin-option:: --adminmedia Django 管理インタフェース用の CSS や JavaScript ファイルを探す場所を Django に 教えるには ``--adminmedia`` オプションを使います。通常、これらのファイルは Django のソースツリーから探索されて配信されるようになっていますが、自作のサイト 用に変更を加えた CSS や JavaScript を指定したい場合には、このオプションを使いま す。 使用例:: django-admin.py runserver --adminmedia=/tmp/new-admin-style/ .. django-admin-option:: --noreload 自動リロード機能の使用を無効にするには ``--noreload`` オプションを使います。 これが意味するところは、サーバの稼働中にいかなる Python コードの変更も検知 *せず* 既にメモリ上に読み込まれている Python モジュールが利用されます。 使用例:: django-admin.py runserver --noreload 異なる IP アドレスとポート番号を使用する例 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 に静的メディ アを提供させたければ、 :ref:`静的なファイルの提供方法 ` を参照してください。 shell ----- Python の対話インタプリタを起動します。 IPython_ がインストールされている場合、Django は IPython を使おうとします。 IPython がインストールされていて、かつ「普通の」インタプリタを使いたいのな ら、以下のように ``--plain`` オプションを使って下さい:: django-admin.py shell --plain .. _IPython: http://ipython.scipy.org/ sql ------------------------- 指定した appname の CREATE TABLE SQL 文を出力します。 sqlall ---------------------------- 指定した appname の CREATE TABLE および初期カスタム SQL の発行、データ入力 のための SQL 文を出力します。 初期カスタム SQL の指定方法は ``sqlcustom`` の説明を参照してください。 sqlclear ------------------------------ 指定した appname の DROP TABLE SQL 文を出力します。 sqlcustom ------------------------------- 指定した appname のカスタム SQL 文を出力します。 このコマンドは、指定した各アプリケーションのモデルについて、 ```` をアプリケーションの名前、 ```` をモデルの名前を全て小文字にした 文字列として、 ``/sql/.sql`` という名前のファイルを探し ます。例えば、 ``news`` というアプリケーションで ``Story`` というモデルが定 義されていれば、 ``sqlcustom`` は ``news/sql/story.sql`` というファイルを探 して読みだし、その内容をこのコマンドの出力の末尾に追加します。 各 SQL ファイルには、有効な SQL を入れることになっています。 SQL ファイルの 内容は、モデルのテーブル生成文を全て実行した後に、データベースに直接パイプ されます。テーブルに対して変更を加えたり、 SQL 関数をデータベースに組み込む には、この SQL フックを使ってください。 SQL ファイルの処理順には決まりがありません。 sqlflush -------- `flush`_ コマンドによって実行されるのと等価な SQL 文を出力します。 sqlindexes -------------------------------- 指定したアプリケーションに対する CREATE INDEX SQL 文を出力します。 sqlreset ------------------------------ 指定した appname に対する DROP TABLE SQL 文を出力し、 その後で CREATE TABLE SQL 文を出力します。 sqlsequencereset -------------------------------------- 指定した appname のシークエンスをリセットするためのSQL 文を出力します。 Sequences are indexes used by some database engines to track the next available number for automatically incremented fields. Use this command to generate SQL which will fix cases where a sequence is out of sync with its automatically incremented field data. startapp ------------------ 現在のディレクトリに、 appname に指定した名前の Django アプリケーショ ンディレクトリ階層を作成します。 startproject -------------------------- 現在のディレクトリに、 projectname に指定した名前の Django プロジェク トディレクトリ階層を作成します。 ``--settings`` オプションを指定して ``django-admin.py`` を呼び出したときや、 環境変数 ``DJANGO_SETTINGS_MODULE`` が指定されていると、このコマンドを使え ません。 ``startproject`` を使いたければ、 ``--settings`` オプションを外し、 ``DJANGO_SETTINGS_MODULE`` を unset してください。 .. _django-admin-syncdb: syncdb ------ ``INSTALLED_APPS`` に登録されており、まだテーブルを作成していないアプリケー ション全てのテーブルを作成します。 このコマンドは、新たなアプリケーションをプロジェクトに追加し、データベース にインストールしたい場合に使って下さい。アプリケーションには、 Django に付 属しているアプリケーションで、デフォルトで ``INSTALLED_APPS`` に入っている ものも含みます。新たなプロジェクトを開始する際には、このコマンドを実行して デフォルトのアプリケーションをインストールする必要があります。 .. admonition:: ``syncdb`` は既存のテーブルを置き換えません ``syncdb`` は、インストールされていないモデルのテーブルしか作成しません。 すでにインストールされているモデルクラスに変更を行っても、それに合わせる ように ``ALTER TABLE`` を発行することは *決してありません* 。モデルクラ スやデータベーススキーマに対する変更には、何らかの形であいまいな部分があ るものです。そのあいまいな部分に対して、 Django どのように変更を適用すべ きか正しく判断せねばならないとすれば、変更の過程で重要なデータが失われる というリスクが生まれてしまいます。 モデルに変更を適用した後、変更に合わせてデータベーステーブルも置き換えた いのなら、 ``sql`` コマンドを使って新たな SQL を出力し、既存のテーブルス キーマと比較して、手動で変更を適用してください。 ``django.contrib.auth`` アプリケーションをインストールした場合には、 ``syncdb`` はスーパユーザを作成するか尋ねます。 ``syncdb`` はまた、 ``initial_data`` という名前で、適切な拡張子 (``json`` や ``xml`` など) のフィクスチャを探してインストールします。フィクスチャデー タファイルの詳細は ``loaddata`` のドキュメントを参照してください。 --noinput ~~~~~~~~~ ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には ``--noinput`` オプションを使います。対話を必要とせずに ``django-admin.py`` を実行する自動化されたスクリプトで役に立ちます。 test ---- インストールされている全てのモデルについてテストを実行します。 詳しくは :ref:`Django アプリケーションのテスト ` を参照して ください。 --noinput ~~~~~~~~~ ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には ``--noinput`` オプションを使います。対話を必要とせずに ``django-admin.py`` を実行する自動化されたスクリプトで役に立ちます。 testserver -------------------------------- .. versionadded:: 1.0 指定したフィクスチャを使って、 (``runserver`` と同様に) 開発用サーバを起動 します。 例えば、次のコマンド:: django-admin.py testserver mydata.json を実行すると、以下のようなステップを実行します: 1. :ref:`topics-testing` 手順に従って、テストデータベース を生成します。 2. 指定したフィクスチャを使ってテストデータベースに値を入れます (フィク スチャの説明は ``loaddata`` ドキュメントを参照してください)。 3. 生成したテストデータベースを使って (``runserver`` と同様に) 開発サー バを実行します。 ``testserver`` が便利な局面はいくつかあります: * 特定のフィクスチャデータに対するビューの動作を調べるための :ref:`ユニットテスト ` を書いている際に、ブラウザでの 表示を手動で調べるのに ``testserver`` を使えます。 * Django アプリケーションを開発していて、「無垢の状態の」データベースを 使って操作してみたいとしましょう。データベースを (前述の ``dumpdata`` コマンドを使って) フィクスチャとしてダンプしておき、 ``testserver`` を使って Web アプリケーションを実行すれば、アプリケーション上でどんな 操作を行っても、変更はテストデータベースにしか加えられないので、好き にデータベースを「汚せ」ます。 ``runserver`` は動作中に Python のソースコード上に加えられた変更を自動的に 検出しますが、 ``testserver`` は検出しません。ただし、テンプレートへの変更 は検出します。 --addrport [port number or ipaddr:port] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 validate -------- インストールされている (``INSTALLED_APPS`` に登録されている) 全てのモ デルを検証 (validate) し、エラーがあれば標準出力に出力します。 デフォルトのオプション ====================== 各々のサブコマンドの独自のオプションの他に、以下の共通のオプションがありま す: --pythonpath ------------ 使用例:: django-admin.py syncdb --pythonpath='/home/djangoprojects/myproject' 指定したファイルシステムパスを Python の `import 検索パス`_ に追加 します。このオプションを指定しない場合、 ``django-admin.py`` は環境変 数 ``PYTHONPATH`` を使います。 ``manage.py`` は Python パスをきちんと設定してくれるので、このオプション は必要ありません。 .. _`import 検索パス`: http://diveintopython.org/getting_to_know_python/everything_is_an_object.html --settings ---------- 使用例:: django-admin.py init --settings=mysite.settings 管理対象のプロジェクトの設定モジュールを明示的に指定します。設定モジュー ルは Python のパッケージ表現構文、すなわち "mysite.settings" のような形式で 指定します。このオプションを指定しない場合、 ``django-admin.py`` は環境変数 ``DJANGO_SETTINGS_MODULE`` を使います。 ``manage.py`` はデフォルトで現在のプロジェクトの ``settings.py`` を使うので、 通常はこのオプションは必要ありません。 --traceback ----------- 使用例:: django-admin.py syncdb --traceback デフォルトでは、 ``django-admin.py`` はエラーが起きるたびに簡単なエラーメッ セージを表示します。 ``--traceback`` を指定すると ``django-admin.py`` は 例外が送出された際に完全なスタックトレースを出力します。 .. _django-admin-verbosity: --verbosity ~~~~~~~~~~~ ``django-admin.py`` のメッセージの通知やデバッグ情報のコンソールへの出力量を 指定するには ``--verbosity`` を使います。 * ``0`` だと、何も出力しません。 * ``1`` だと、通常の出力 (デフォルト) です。 * ``2`` だと、詳細に出力します。 使用例:: django-admin.py loaddata --verbosity=2 .. _Extra niceties: その他のからくり ================ シンタクスの色づけ ------------------ SQL 文を標準出力に出力する ``django-admin.py`` / ``manage.py`` コマンドは、 端末が ANSI カラー出力をサポートする場合にはコードを色づけして表示します。 ただし、出力を別のプログラムにパイプしている場合には色づけを行いません。 bash での補完 ------------- bash シェルを使っているのなら、 Django の bash 補完スクリプトのインストール を検討してみてください。スクリプトは Django 配布物の ``extras/django_bash_completion`` にあります。 bash 補完機能を使うと、 ``django-admin.py`` および ``manage.py`` コマンドをタブ補完できるようになり ます。例えば: * ``django-admin.py`` とタイプします。 * [TAB] を押すと、利用可能な全てのオプションを表示します。 * ``sql`` とタイプして [TAB] を押すと、 ``sql`` で始まる全てのオプショ ンを表示します。 アクションを自作するには、 :ref:`howto-custom-management-commands` を参照し てください。