Django 1.4 documentation

ホーム | 目次 | 索引 | モジュール一覧

« 前へ | 上へ | 次へ »

はじめての Django アプリ作成、その 1

revision-up-to:17812 (1.4)

さあ、例を交えながら学んでゆきましょう。

このチュートリアルでは、簡単な投票 (poll) アプリケーションの作成に取り組ん でもらいます。

Poll アプリケーションは、

• ユーザが投票したり結果を表示したりできる公開用サイト
• 投票項目の追加、変更、削除を行うための管理 (admin) サイト

の二つの部分に分かれています。

Django は既にインストール済み として、説明を進めます。 Django がインストールされているかどうかは、Python 対話シェルを起動して import django を実行してみればわかります。エラーなく import できるなら、 Django はインストールされています。

困ったときは:

このチュートリアルを進めてゆく上で困ったことがあったら、 django-users や irc.freenode.net の #djangoチャネル で誰か助けてくれそ うな人と話してみてください。

プロジェクトの作成

初めて Django を使うのなら、最初のセットアップを行う必要があります。通常は、 Django の プロジェクト (project) を構成するコードを自動生成 します。プロジェクトとは、データベースの設定や Django 固有のオプション、ア プリケーション固有の設定などといった、個々の Django インスタンスの設定をあ つめたものです。

コマンドラインから、コードを置きたい場所に cd して、以下のコマンドを 実行してください。

django-admin.py startproject mysite

現在のディレクトリに mysite ディレクトリが作成されます。

ディストリビューションパッケージでスクリプトの名前が違うかも

もし apt-get や yum のような Linux ディストリビューションのパッケージ マネージャを使って Django をインストールした場合、 django-admin.py は django-admin に名前が変更されている場合があります。その場合は、 これ以降のドキュメント内で出てくるそれぞれのコマンドから .py を削除 して操作を続けてください。

Max OS X でのパーミッションに関するエラー

Mac OS X を使っている場合、 django-admin.py startproject を実行しよ うとすると、 “permission denied” というメッセージが出ることがあります。 OS X のような Unix ベースのシステムでは、ファイルをプログラムとして実行 したい場合に、ファイルに「プログラムとして実行可能」というマークをつけて おく必要があるためです。ファイルに実行可能マークをつけるには、 Terminal.app を起動して、 django-admin.py を収 めているディレクトリに ( cd コマンドで) 移動して、 sudo chmod +x django-admin.py を実行してください。

Note

プロジェクトの名前を付けるとき、組み込みの Python モジュールや Django のコンポーネントの名前を使わないようにしてください。とりわけ、 django (Django 自体と名前が衝突します) や test (組み込みの Python パッケージ名と名前が衝突します) を使わないようにしましょう。

python setup.py ユーティリティで Django をインストールしたのなら、 django-admin.py はシステムパスのどこかにあるはず です。パス上になければ、 site-packages/django/bin にあります。 site-packages は Python インストールディレクトリの中にあります。パス上 のどこか、例えば /usr/local/bin に django-admin.py へのシンボリックリンクを張って おきましょう。

コードはどこに置くの？

PHP の経験があるなら、これまでは Web サーバのドキュメントルート下 (/var/www といった場所) にコードを配置してきたことでしょう。 Django ではそうする必要はありません。むしろ Python コードをドキュメントルート 下に置くのは賢明ではありません。コードをドキュメントルート下に置くと、 誰かがコードを Web を介して読めるようになってしまうからです。これは安全 上よろしくありません。

コードはドキュメントルートの 外 、例えば /home/mycode の ような場所に置きましょう。

startproject が何を作成したかをみてみましょう:

mysite/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        wsgi.py

自分のレイアウトと違う場合

デフォルトのプロジェクトのレイアウトが最近変わりました。もし、フラットな レイアウトの場合 (内側の mysite/ ディレクトリがない場合) は、この チュートリアルのバージョンとは違う Django のバージョンを使用していること でしょう。古いチュートリアルを参照するか、新しいバージョンの Django を 入手してください。

ファイルはそれぞれ以下のような役割を持っています:

• 外側の mysite/ ディレクトリは、このプロジェクトのただの入れ物です。 名前は Django に関係しませんので、好きな名前に変更できます。
• manage.py: Django プロジェクトに対する様々な操作を行うための コマンドラインユーティリティです。詳しくは django-admin.py と manage.py を参照してください。
• 内側の mysite/ ディレクトリは、このプロジェクトの本当の Python パッケージです。この名前が Python パッケージの名前であり、 import の際に 使用する名前です (例えば import mysite.settings) 。
• mysite/__init__.py: このディレクトリが Python パッケージであることを Python に知らせるための空のファイルです。(Python の初心者は、 Python の公式 ドキュメントの パッケージの詳しい説明 を読んで下さい。)
• mysite/settings.py: Django プロジェクトの設定ファイルです。 設定の仕組みは Django の設定 を参照してください。
• :file:mysite/urls.py: Django プロジェクトの URL 宣言、いうなれば Django サイトにおける「目次」に相当します。詳しくは URL ディスパッチャ を参照 してください。
• mysite/wsgi.py: WSGI互換のある Web サーバでプロジェクトを動かすための エントリーポイントです。詳しくは WSGI 環境にデプロイする方法 を参照 してください。

開発用サーバ

プロジェクトがうまく動作するか確かめましょう。外側の mysite ディレク トリに移り、 python manage.py runserver を実行してください。以下のような メッセージが表示されるはずです:

Validating models...
0 errors found.

Django version 1.4, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

これで、 Django 開発サーバを起動しました。 Django 開発サーバは Python だけ で書かれた軽量な Web サーバです。このサーバは、開発を迅速に行い、運用に適し た状態になるまで Apache のような運用サーバの設定をいじらなくても良いように するためのものです。

ここでちょっと注意しておきましょう。このサーバは開発中の利用だけを考えて作 られているため、絶対に運用環境では使わないようにしてください (筆者たちの専 門は Web フレームワークであって、 Web サーバではありません)。

さあ、これでサーバが起動したので、ブラウザで http://127.0.0.1:8000/ にアク セスしてみてください。 “Welcome to Django” と表示された、明るいパステル調の ライトブルーのページが出るはずです。やったね！

ポート番号の変更

デフォルトでは、 runserver コマンドを実行すると、開発用サー バはポート番号 8000 で起動します。サーバのポート番号を変更したければ、 コマンドライン引数で指定します。例えばポート番号を 8080 にしたければ以 下のようにしてください:

python manage.py runserver 8080

サーバの IP を指定するときには、ポート番号も一緒に指定します。従って、 全ての IP からのリクエストを受け付ける (サーバを他のコンピュータから可 視にする) には、以下のようにします:

python manage.py runserver 0.0.0.0:8000

開発サーバの詳細な説明は runserver のリファレンスを参照して ください。

Database の設定

それでは、 mysite/settings.py を編集しましょう。 mysite/settings.py は Django の設定を表現する通常の Python モジュール です。 DATABASES 'default' の中の以下のキーを書き換えて、お使 いのデータベースへの接続パラメタに合わせましょう:

• ENGINE – 'django.db.backends.postgresql_psycopg2', 'django.db.backends.mysql', 'django.db.backends.sqlite3' または 'django.db.backends.oracle' のいずれかです。 他にも いくつか あります。

• NAME` – データベースの名前です。 SQLite を使っている場合には データベースファイルのフルパス (絶対パス) にします。 指定したパスのファイルが存在しなければ、 Django は最初にデータベースの同期 を実行したときにファイルを生成します (後で解説します)。

  パスを指定するときには、 Windows 環境でも必ずスラッシュ (/) を区切り文字 に使ってください (例: C:/homes/user/mysite/sqlite3.db)

• USER – データベースのユーザ名です (SQLite では使いません)。

• PASSWORD – データベースのパスワードです。 (SQLite では使いません)。

• HOST – データベースのあるホストです。データベースサーバが物理的に 同じマシン上にあるのなら空文字列にしておきます。(SQLite では使いません)。

データベースをあまり扱ったことがないのなら、 ENGINE に 'django.db.backends.sqlite3' を指定して SQLite を使用することをお勧めしま す。 SQLite はバージョン 2.5 以降の Python に組み込まれているので、特にインス トールする必要がありません。

Note

PostgreSQL や MySQL を使っている場合、この時点でデータベースを作成して おいてください。データベースを作成するには、データベースの対話プロンプ トで “CREATE DATABASE database_name;” を実行します。

SQLite を使う場合には、予め何か作成しておく必要はありません。データベー スファイルは、必要に応じて自動的に生成されます。

settings.py を編集する際、 TIME_ZONE にタイムゾーンをセット してください。デフォルト値はアメリカのセントラルタイムゾーン (シカゴ) になり ます。また、ファイルの末尾近くにある INSTALLED_APPS 設定に注意して ください。この変数には、現在の Django インスタンスで有効な全ての Django アプリ ケーションの名前が入ります。アプリケーションは複数のプロジェクトで利用でき、 配布もできます。

デフォルトでは INSTALLED_APPS には以下のアプリケーションが入って います。これらのアプリケーションはいずれも Django に付属のものです:

• django.contrib.auth – 認証システムです。
• django.contrib.contenttypes – コンテンツタイプフレームワークです。
• django.contrib.sessions – セッションフレームワークです。
• django.contrib.sites – 一つの Django で複数のサイトを管理する ためのフレームワークです。
• django.contrib.messages – メッセージフレームワークです。
• django.contrib.staticfiles – 静的なファイルを管理するための フレームワークです。

これらの機能はよく使われるのでデフォルトで付属しています。

上に挙げたアプリケーションは、必ず少なくとも一つのデータベーステーブルを使 います。そこで、アプリケーションを使う前にテーブルを作成しておく必要があり ます。テーブルを作成するには以下のコマンドを使います:

python manage.py syncdb

syncdb コマンドは INSTALLED_APPS 設定を探し、 settings.py のデータベース設定に従ってデータベース上に必要なテーブ ルを作成します。コマンドが生成したデータベースを示すメッセージが表示され、 認証システムで使うスーパユーザアカウントを作成したいかどうか尋ねるプロンプ トが出ます。アカウントを作成しておきましょう。

Django がどんなテーブルを作成したか興味があるなら、データベースのコマンドラ インクライアントを使って、 \dt (PostgreSQL), SHOW TABLES; (MySQL), あるいは .schema (SQLite) と入力してみましょう。

ミニマリストのために

上で述べたように、デフォルトのアプリケーションはよくあるケースに対応す るために入っているにすぎず、誰もが必要としているわけではありません。デ フォルトアプリケーションの一部なり全部なりが必要なければ、 syncdb を実行する前に該当する行をコメントアウトするか削除し てかまいません。 syncdb コマンドは INSTALLED_APPS にあるアプリケーションのテーブルを生成しているにすぎません。

モデルの作成

さあ、これで自分用の環境、すなわちプロジェクトが立ち上がり、作業にとりかか る準備ができました。

Django で書いたアプリケーションは Python パッケージからなり、 ある規約に従っ て Python パス のどこかに置かねばなりません。Django にはアプリケーション の基本的なディレクトリ構造を作成するためのユーティリティがついてくるので、 ディレクトリの作成は気にせずコードの記述に集中できます。

プロジェクトとアプリケーション

プロジェクトとアプリケーションの違いとは何でしょうか？アプリケーション とは、実際に何らかの処理を行う Web アプリケーションを指します。例えばブ ログシステムや公開レコードのデータベース、単純な投票アプリといった具合 です。プロジェクトとは、あるウェブサイト向けに設定とアプリケーションを 集めたものです。一つのプロジェクトには複数のアプリケーションを入れられ ます。また、一つのアプリケーションは複数のプロジェクトで使えます。

このチュートリアルでは、簡単のため、投票アプリケーションを mysite ディレクトリの中に作ります。その結果、アプリケーションはプロジェクトとカッ プリングします。すなわち、 poll アプリケーション内の Python コードは mysite.polls のように参照されることになります。チュートリアルの後半では、 アプリケーションを配布用に脱カップリングする方法について議論する予定です。 アプリケーションは、 Python パス のどこにでも置くことができます。この チュートリアルでは、投票アプリケーションを manage.py ファイルのすぐ 隣に作り、 mysite のサブモジュールというより、自身のトップレベルのモジュ ールとして import できるようにします。

アプリケーションを作成するには、 manage.py と同じディレクトリに入っ て、以下のようなコマンド:

python manage.py startapp polls

を入力します。このコマンドは polls というディレクトリを作成し、その 中に以下のようにファイルを配置します:

polls/
    __init__.py
    models.py
    tests.py
    views.py

このディレクトリ構造こそが、 poll アプリケーションの全体像です。

Django でデータベース Web アプリケーションを書くための最初のステップは、モ デルの定義です。本質的には、データベースのレイアウトと、追加のメタデータの 定義です。

設計哲学

モデルは、手持ちのデータに対する唯一 (single) の決定的な (definitive) ソースです。モデルには自分が格納したいデータにとって必要不可欠なフィー ルドと、そのデータの挙動を収めます。 Django は DRY 則 に従っ ています。Django のモデルの目的は、ただ一つの場所でデータモデルを定義し、 そこから自動的にデータを取り出すことにあります。

これから開発する簡単な poll アプリケーションでは、投票項目 (poll) と選択肢 (choice) の二つのモデルを作成します。 poll には質問事項 (question) と公開日 (publication date) の情報があります。 choice には選択肢のテキストと投票数 (vote) という二つのフィールドがあります。各 choice は一つの poll に関連づけ られています。

Django では、こうした概念を簡単な Python クラスで表現できます。 polls/models.py ファイルを以下のように編集してください:

from django.db import models

class Poll(models.Model):
    question = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    poll = models.ForeignKey(Poll)
    choice = models.CharField(max_length=200)
    votes = models.IntegerField()

コードは単純明解ですね。各モデルは一つのクラスで表現され、いずれも django.db.models.Model のサブクラスです。各モデルには複数のクラス 変数があり、個々のクラス変数はモデルのデータベースフィールドを表現していま す。

各フィールドは Field クラスのインスタンスとして 表現されています。例えば、 CharField は 文字のフィールドで、 DateTimeField は日時フィー ルドです。こうしたクラスは、各フィールドにどのようなデータ型を記憶させるか を Django に教えます。

models.*Field` インスタンスの名前 (question や pub_date) はフィールドの名前で、計算機にとって扱いやすい名前を付けます。この名前は Python コードの中で使いますし、データベースではカラム名に使います。

django.db.models.Field の第一固定引数には、オプションとして人間可 読なフィールド名も指定できます。このフィールド名は Django の二つの内省 (introspection) 機能で使う他、ドキュメントとしての役割も果たします。人間可 読なフィールド名を指定しない場合、 Django は機械可読な名前を使います。上の 例では、 Poll.pub_date にだけ人間可読なフィールド名を指定しました。モデ ルの他のフィールドでは、フィールドの機械可読な名前は人間可読な名前としても 十分なので定義していません。

Field クラスの中には必須の引数を持つものがありま す。例えば CharField には max_length を指定する必要があります。この引 数はデータベーススキーマで使われる他、後で述べるバリデーションでも使われま す。

最後に、 ForeignKey を使ってリレーションが定義さ れていることに注意して下さい。このリレーションは、各 Choice が一つの Poll に関連づけられていることを Django に教えます。 Django は多対一、多対多、一 対一といった、広く使われているリレーション全てをサポートしています。

モデルを有効にする

前述のようなほんのわずかなコードをモデルに書くだけで、 Django はたくさんの 情報を手にします。このコードを使って、 Django は:

• アプリケーションのデータベーススキーマを作成 (CREATE TABLE 文を実 行) できます。
• Poll や Choice オブジェクトに Python からアクセスするためのデータベー ス API を作成できます。

ただし、その前に polls アプリケーションをインストールしたことをプロジェ クトに教えてやる必要があります。

設計哲学

Django アプリケーションは「プラガブル (pluggable)」です。アプリケーショ ンは特定の Django インストールに結び付いていないので、アプリケーション を複数のプロジェクトで使ったり、単体で配布したりできます。

再度 settings.py ファイルを編集して、 INSTALLED_APPS 設 定を変更し、 'polls' を入れます。以下のようになるはずです:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # Uncomment the next line to enable the admin:
    # 'django.contrib.admin',
    # Uncomment the next line to enable admin documentation:
    # 'django.contrib.admindocs',
    'polls',
)

これで Django は polls アプリケーションが入っていることを知りました。 もう一つコマンドを実行してみましょう:

python manage.py sql polls

以下のような (polls アプリケーション用の CRATE TABLE SQL 文) が表示されるは ずです:

BEGIN;
CREATE TABLE "polls_poll" (
    "id" serial NOT NULL PRIMARY KEY,
    "question" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id") DEFERRABLE INITIALLY DEFERRED,
    "choice" varchar(200) NOT NULL,
    "votes" integer NOT NULL
);
COMMIT;

以下の点に注意してください:

• 実際に出力される SQL 文は、使っているデータベースによって変わります。
• テーブル名はアプリケーションの名前 (polls) とモデルの小文字表記 (poll および choice) を使って自動的に生成されます (この挙動は オーバライドできます。)
• 主キー (primary key, ID) は自動的に生成されます (この挙動もオーバライ ド可能です)
• 便宜上、 Django は外部キーのフィールド名に "_id" を追加します。も ちろんこの挙動もオーバライド可能です。
• 外部キーのリレーションは REFERENCES 文で明示的に作成されます。
• SQL 文は使っているデータベースに応じて細かく調整されます。従って、 auto_increment (MySQL)、 serial (PostgreSQL)、 integer primary key (SQLite) といったデータベース固有のフィールド タイプは自動的に指定されます。クオートの仕方、すなわち一重と二重のど ちらの引用符を使うか、といったことも自動で調整します。このチュートリ アルの作者は PostgreSQL を使っており、例題での出力は PostgreSQL の文 法に準じています。
• sql コマンドを実行しても、実際にデータベースで SQL を実行 するわけではありません。 sql コマンドは、ユーザが Django の挙動を 知りたいと考えたときのため、単に SQL 文をスクリーンに表示しているだけ です。必要なら、この SQL 文をコピーしてデータベースクライアントのプロ ンプトにペーストできますが、後ですぐ述べるように、 Django では SQL を データベースに commit させる簡単な方法を提供しています。

興味があるなら、以下のコマンドも実行してみてください:

• python manage.py validate – モデルの構成にエ ラーがないか調べます。
• python manage.py sqlcustom polls – 各アプリケー ション向けに定義しておいた、カスタマイズ (テーブル形式の変更や制約) 用の SQL 文を出力します。
• python manage.py sqlclear polls – アプリケーショ ン用のテーブルのうち、データベース上に存在するものについて必要に応じ て DROP TABLE 文を出力します。
• python manage.py sqlindexes polls – アプリケー ション用の CREATE INDEX 文を出力します。
• python manage.py sqlall polls – ‘sql’, ‘sqlcustom’, ‘sqlindexes’ コマンドを合わせたものです。

これらのコマンドの出力を見れば、水面下で実際に行われていることを理解する助 けになるでしょう。

syncdb を再度実行して、モデルテーブルをデータベース上に作成しま しょう:

python manage.py syncdb

syncdb コマンドは INSTALLED_APPS に登録されているアプ リケーションのうち、データベース上にまだ存在しないものに対して sqlall で生成した SQL を生成します。これによって、最後に syncdb を実行した時以後に新たにプロジェクトに追加されたアプリケー ションのテーブルと初期データ、インデクスを生成します。 syncdb はその都度存在しないテーブルだけを生成するので、繰り返し実行してもかまいま せん。

manage.py ユーティリティでできることについては django-admin.py のドキュメント を読んで下さい。

API で遊んでみる

さて、Python 対話シェルを起動して、 Django が提供する API で遊んでみましょ う。 Python シェルを起動するには、以下のコマンドを実行します:

python manage.py shell

単に “python” を実行しないのは、 Django に settings.py ファイルへの import パスを与える DJANGO_SETTINGS_MODULE の環境変数を manage.py で設定しているからです。

manage.py を使わずに済ませる方法

manage.py を使いたくなくても、問題はありません。環境変数 DJANGO_SETTINGS_MODULE を mysite.settings に設定して、 manage.py と同じディレクトリで python を実行してください (または import mysite が通るように、ディレクトリが Python のパス上 にあるようにしてください) 。

詳しくは django-admin.py のドキュメント を参 照してください。

シェルに入ったら、 データベース API の世界を探検 してみましょう:

>>> from polls.models import Poll, Choice # モデルクラスを import します。

# まだ Poll は一つもできていません。
>>> Poll.objects.all()
[]

# 新たな Poll を作成しましょう。
# デフォルト設定ファイルでタイムゾーンへのサポートが使用可能になって
# いるので、 Django は pub_date に対して tzinfo を伴った datetime を
# 期待します。 datetime.datetime.now() の代わりに timezone.now() を使用
# してください。
>>> from django.utils import timezone
>>> p = Poll(question="What's new?", pub_date=timezone.now())

# 出来たオブジェクトをデータベースに保存します。 save() は明示的に呼ば
# ねばなりません。
>>> p.save()

# これでオブジェクトに ID が割り当てられました。お使いのデータベースに
# よっては、この値は "1" ではなく "1L" のときもあります。心配することは
# ありません。単にデータベースバックエンドが Python 長整数型で値を返す
# ようになっているだけのことです。
>>> p.id
1

# データベースの各カラムに Python の属性としてアクセスします。
>>> p.question
"What's new?"
>>> p.pub_date
datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)

# 属性を変更して save() を呼び出すとカラムの値を変更します。
>>> p.question = "What's up?"
>>> p.save()

# objects.all() はデータベース上の全ての Poll を返します。
>>> Poll.objects.all()
[<Poll: Poll object>]

おっと、ちょっと待って下さい。 <Poll: Poll object> なんて全然親切な表現 ではありませんね。そこで (polls/models.py ファイルに定義されている) polls 関係のモデルを少し修正して、 Poll と Choice に __unicode__() メソッドを追加しましょう:

class Poll(models.Model):
    # ...
    def __unicode__(self):
        return self.question

class Choice(models.Model):
    # ...
    def __unicode__(self):
        return self.choice

__unicode__() をモデルに追加しておく重要性は、 対話プロンプトで扱うときに精神的によいだけでなく、Django が自動生成する管理 インタフェースのいたるところでオブジェクトの表現 (representation) が使われ ているという点にもあります。

なぜ __str__() ではなく __unicode__() を使うの？

Python に詳しければ、普段は __str__() で はなく __unicode__() を実装していることで しょう。 __unicode__() を使うのは、Django のモデルがデフォルトで Unicode を扱うからです。 Django では、データベー ス上に保存された文字列の情報は、取り出すときに全て Unicode 型に変換され ます。

Django のモデルは、デフォルトで __str__() メソッドを実装していて、中で __unicode__() を呼び出して、得た結果を UTF-8 のバイト文字列に変換しています。従って、 unicode(p) は Unicode 文字列を返し、 str(p) は UTF-8 でエンコードされた通常の文字 列を返します。この仕様がよくわからなければ、とにかく __unicode__() をモデルに追加するのだと覚 えておいてください。なにはともあれ、それでうまく動作します。

__unicode__() は通常の Python メソッドという ことに注意してください。デモ用にカスタムのメソッドを追加してみましょう:

import datetime
from django.utils import timezone
# ...
class Poll(models.Model):
    # ...
    def was_published_recently(self):
        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)

import datetime と from django.utils import timezone で Python の 標準モジュール datetime と Django のタイムゾーン関連ユーティリティの django.utils.timezone を参照していることに注意してください。もし Python でタイムゾーンを取り扱うことに不慣れな場合は、 タイムゾーン で勉強できます。

python manage.py shell を実行して、Python 対話シェルに戻りましょう:

>>> from polls.models import Poll, Choice

# __unicode__() がきちんと働いていることを確認します。
>>> Poll.objects.all()
[<Poll: What's up?>]

# Django は様々なデータベース照合 API を提供しています。 API はキーワー
# ド引数で隅々まで操作できます。
>>> Poll.objects.filter(id=1)
[<Poll: What's up?>]
>>> Poll.objects.filter(question__startswith='What')
[<Poll: What's up?>]

# 2012 年の Poll を取り出しましょう。
>>> Poll.objects.get(pub_date__year=2012)
<Poll: What's up?>

>>> Poll.objects.get(id=2)
Traceback (most recent call last):
    ...
DoesNotExist: Poll matching query does not exist.
>>> Poll.objects.filter(question__startswith='What')
[<Poll: What's up?>]

# 主キーの照合はよくあることなので、 Django は主キーの厳密一致を照合
# するショートカットを提供しています。
# 以下の実行文は Poll.objects.get(id=1) と同じです。
>>> Poll.objects.get(pk=1)
<Poll: What's up?>

# カスタムメソッドが動作するか確かめてみましょう。
>>> p = Poll.objects.get(pk=1)
>>> p.was_published_recently()
True

# Poll に二つの Choice を指定しましょう。 create を呼び出すと、新たな
# Choice オブジェクトを生成し、 INSERT 文を実行し、 Poll からアクセス可
# 能な Choice オブジェクトの集合に追加して、新たに作成された Choice オ
# ブジェクトを返します。 Django は API を通してアクセス出来る "あちら側"
# の外部キー (例えば poll の choice) を保持する set を作ります。
>>> p = Poll.objects.get(pk=1)

# 関連するオブジェクトの set から choice を表示します。現在は空です。
>>>> p.choice_set.all()
[]

# 3つの choice を作ります。
>>> p.choice_set.create(choice='Not much', votes=0)
<Choice: Not much>
>>> p.choice_set.create(choice='The sky', votes=0)
<Choice: The sky>
>>> c = p.choice_set.create(choice='Just hacking again', votes=0)

# Choice オブジェクトは自分に関連づけされた Poll オブジェクトに
# アクセスするための API を備えています。
>>> c.poll
<Poll: What's up?>

# 逆も行えます: Poll オブジェクトから Choice オブジェクトにアクセスでき
# ます。
>>> p.choice_set.all()
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]
>>> p.choice_set.count()
3

# API は必要に応じて自動的にリレーションを追跡します。リレーションを辿
# るには二重アンダースコアを使います。この表記法には制限がなく、何段階
# でも連鎖できます。以下の例では、 pub_date が 2012 の全ての Poll に関
# 連づけられている Choice を返します。
>>> Choice.objects.filter(poll__pub_date__year=2012)
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]

# choice を一つ削除しましょう。 delete() を使います。
>>> c = p.choice_set.filter(choice__startswith='Just hacking')
>>> c.delete()

リレーションモデルの詳細は、 リレーションオブジェクトリファレンス を 参照してください。 API を通じたフィールドの照合のためのダブルアンダースコア の使い方の詳細は、 フィールドの照合 を参照してください。 データベース API の詳細は、 データベース API リファレンス を参照してください。

API を使いこなせるようになったら、 チュートリアルその 2 に進んで、Django が自動生成 する管理インタフェースを動かしてみましょう。

Last update:

Oct 26, 2017

« 前へ | 上へ | 次へ »