{"title":"はじめての Django アプリ作成、その2","version":"1.9","locale":"ja","docname":"intro/tutorial02","url":"/ja/1.9/intro/tutorial02/","canonical":"https://djangodocs.dev/ja/1.9/intro/tutorial02/","summary":"このチュートリアルはチュートリアルその 1 の続きです。ここでは、データベースをセットアップして、最初のモデルを作成し、そして Django が自動的に生成してくれる管…","html":"

はじめての Django アプリ作成、その2Link to this heading#

\n

このチュートリアルは チュートリアルその 1 の続きです。ここでは、データベースをセットアップして、最初のモデルを作成し、そして Django が自動的に生成してくれる管理 (admin) サイトについて、簡単なイントロダクションをします。

\n
\n

Database の設定Link to this heading#

\n

それでは、 mysite/settings.py を開いてください。これは、 Django の設定を表現するモジュールレベルの変数を持つ通常の Python モジュールです。

\n

デフォルトでは、データベースとしてSQLiteを利用するように設定されています。もしあなたがデータベースに詳しくなく、もしくはDjangoに興味を持って試してみているところならば、SQLiteを利用するのが最も簡単でしょう。SQLiteはPythonに標準で組み込まれているため、データベースを利用するために何か別のものをインストールする必要がありません。ただし、あなたが実際に利用されるプロジェクトを開発するならば、いつか将来にデータベースを変更する手間を考えると、PostgreSQLのように、より堅牢なデータベースを利用したくなるでしょう。

\n

他のデータベースを使いたい場合、適当な データベースのバインディング をインストールして、設定ファイルの DATABASES の``'default'`` アイテム内の以下のキーを、それぞれデータベースの接続設定に合ったものに変更してください。

\n\n

データベースとして SQLite を使っていない場合、 USER や PASSWORD そして HOST などの追加設定を加える必要があります。詳細については  :setting:`DATABASES のリファレンスドキュメントを参照してください。

\n\n

mysite/settings.py を編集する際、 TIME_ZONE に自分のタイムゾーンも設定します。

\n

同じく、ファイル先頭にある INSTALLED_APPS に注意してください。これはこのDjangoインスタンスの中で有効化されているすべてのDjangoアプリケーションの名前を保持しています。アプリは複数のプロジェクトによって使用されることができますし、また、他の開発者が彼らのプロジェクトで使用するためにパッケージして配布することもできます。

\n

デフォルトでは、 :settings:`INSTALLED_APPS` には以下のアプリケーションがはいっています。

\n\n

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

\n

これらのアプリケーションは最低1つデータベースのテーブルを使うので、使い始まる前にデータベースにテーブルを作る必要があります。以下のコマンドを実行してください:

\n
Shell
$ python manage.py migrate\n
\n

migrate コマンドは INSTALLED_APPS の設定を参照するとともに、 mysite/settings.py ファイルのデータベース設定に従って必要なすべてのデータベースのテーブルを作成します。このデータベースマイグレーションはアプリと共に配布されます (これらについては後ほどカバーします)。マイグレーションを実施するたび、メッセージを見ることになります。もしこれに興味を引かれたら、Djangoが作成したテーブルを表示するために、コマンドラインクライアントであなたのデータベースの種類に合わせて \\dt (PostgreSQL)、SHOW TABLES; (MySQL)、 .schema (SQLite)、もしくは SELECT TABLE_NAME FROM USER_TABLES; (Oracle) とタイプしてみましょう。

\n\n
\n
\n

モデルの作成Link to this heading#

\n

これからモデルを定義します -- 追加的なメタデータとともにデータベースのレイアウトを行う、必須の作業です。

\n\n

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

\n

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

\n
polls/models.py
Code
from django.db import models\n\n\nclass Question(models.Model):\n    question_text = models.CharField(max_length=200)\n    pub_date = models.DateTimeField('date published')\n\n\nclass Choice(models.Model):\n    question = models.ForeignKey(Question, on_delete=models.CASCADE)\n    choice_text = models.CharField(max_length=200)\n    votes = models.IntegerField(default=0)\n
\n

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

\n

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

\n

Field インスタンスそれぞれの名前(例: question_text や pub_date)は、機械可読なフィールド名です。このフィールド名はPythonコードで使うとともに、データベースも列の名前として使うことになります。

\n

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

\n

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

\n

Field はいつくかオプションの引数も取れます。今回の場合、 `votes の default 値を 0 に設定しました。

\n

ついに、 ForeignKey を使用したリレーションシップの記述が定義されました。これは、それぞれの``Choice`` が一つの``Question``に関連付けられていることをDjangoに伝えます。Djangoは 多対一、多対多、そして一対一のような一般的なデータベースリレーションシップすべてをサポートします。

\n
\n
\n

モデルを有効にするLink to this heading#

\n

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

\n\n

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

\n\n

mysite/settings.py ファイルをもう一度編集して、 INSTALLED_APPS の設定に文字列``'polls.apps.PollsConfig'``が含まれるよう変更します。そうするとこのようになります:

\n
mysite/settings.py
Code
INSTALLED_APPS = [\n    'polls.apps.PollsConfig',\n    'django.contrib.admin',\n    'django.contrib.auth',\n    'django.contrib.contenttypes',\n    'django.contrib.sessions',\n    'django.contrib.messages',\n    'django.contrib.staticfiles',\n]\n
\n

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

\n
Shell
$ python manage.py makemigrations polls\n
\n

次のようなものが表示されるはずです:

\n
Text
Migrations for 'polls':\n  0001_initial.py:\n    - Create model Choice\n    - Create model Question\n    - Add field question to choice\n
\n

``makemigrations``を実行することで、Djangoにモデルに変更があったこと(この場合、新しいものを作成しました)を伝え、そして変更を*マイグレーション*の形で保存することができました。

\n

マイグレーションはDjangoがモデル(そしてデータベーススキーマでもあります)の変更をディスク上のファイルに保存する方法です。望むならば、新しいモデルをマイグレーションのファイル polls/migrations/0001_initial.py から読むことも出来ます。安心して下さい、Djangoが作成する度にマイグレーションのファイルを読む必要はありません、しかし、Djangoが行った変更を手動で微調整したいというときのために人間可読なファイルとして設計されています。

\n

これは自動でデータベーススキーマを管理するためのマイグレーション実行するとのコマンドです。migrate と呼ばれる、あっという間に完了します、しかし最初は、マイグレーションがどんなSQLを実行するのか見てみましょう。sqlmigrate コマンドはマイグレーションの名前を引数にとってSQLを返します:

\n
Shell
$ python manage.py sqlmigrate polls 0001\n
\n

あなたは次のようなもの (読みやすさのためにそれを再フォーマットした) が表示されるはずです:

\n
SQL
BEGIN;\n--\n-- Create model Choice\n--\nCREATE TABLE "polls_choice" (\n    "id" serial NOT NULL PRIMARY KEY,\n    "choice_text" varchar(200) NOT NULL,\n    "votes" integer NOT NULL\n);\n--\n-- Create model Question\n--\nCREATE TABLE "polls_question" (\n    "id" serial NOT NULL PRIMARY KEY,\n    "question_text" varchar(200) NOT NULL,\n    "pub_date" timestamp with time zone NOT NULL\n);\n--\n-- Add field question to choice\n--\nALTER TABLE "polls_choice" ADD COLUMN "question_id" integer NOT NULL;\nALTER TABLE "polls_choice" ALTER COLUMN "question_id" DROP DEFAULT;\nCREATE INDEX "polls_choice_7aa0f6ee" ON "polls_choice" ("question_id");\nALTER TABLE "polls_choice"\n  ADD CONSTRAINT "polls_choice_question_id_246c99a640fbbd72_fk_polls_question_id"\n    FOREIGN KEY ("question_id")\n    REFERENCES "polls_question" ("id")\n    DEFERRABLE INITIALLY DEFERRED;\n\nCOMMIT;\n
\n

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

\n\n

もし興味があれば python manage.py check を実行することもできます; これはマイグレーションを作成したりデータベースにふれることなくプロジェクトになんの問題がないか確認します 。

\n

migrate を再度実行し、 モデルのテーブルをデータベースに作成しましょう。

\n
Shell
$ python manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, contenttypes, polls, auth, sessions\nRunning migrations:\n  Rendering model states... DONE\n  Applying polls.0001_initial... OK\n
\n

migrate コマンドはすべての適用されていないマイグレーション(Djangoはデータベース内の``django_migrations``と呼ばれる特別なテーブルを利用してどれが適用されているかを追跡しています)を捕捉してデータベースに対してそれを実行します - 重要なのは、モデルに対して行った変更はデータベースのスキーマに同期するということです。

\n

マイグレーションは、データベースやテーブルを削除しまた新しいものを作成する必要なく、プロジェクトを開発するように、いつでもモデルを変更可能とする強力なツールです - データを失うことなしにデータベースをライブでアップグレードするよう特化しています。これらについてチュートリアルの後の部分でより深くカバーします、しかし今は、モデルの変更を実施するための3ステップガイドを覚えておいてください:

\n\n

マイグレーションの作成と適用のコマンドが分割されている理由は、マイグレーションをバージョン管理システムにコミットし、アプリとともに配布するためです。これによって、あなたの開発が容易になるだけでなく、他の開発者や本番環境にとって使いやすいものになります。

\n

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

\n
\n
\n

API で遊んでみるLink to this heading#

\n

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

\n
Shell
$ python manage.py shell\n
\n

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

\n\n

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

\n
Code
>>> from polls.models import Question, Choice   # Import the model classes we just wrote.\n\n# No questions are in the system yet.\n>>> Question.objects.all()\n[]\n\n# Create a new Question.\n# Support for time zones is enabled in the default settings file, so\n# Django expects a datetime with tzinfo for pub_date. Use timezone.now()\n# instead of datetime.datetime.now() and it will do the right thing.\n>>> from django.utils import timezone\n>>> q = Question(question_text="What's new?", pub_date=timezone.now())\n\n# Save the object into the database. You have to call save() explicitly.\n>>> q.save()\n\n# Now it has an ID. Note that this might say "1L" instead of "1", depending\n# on which database you're using. That's no biggie; it just means your\n# database backend prefers to return integers as Python long integer\n# objects.\n>>> q.id\n1\n\n# Access model field values via Python attributes.\n>>> q.question_text\n"What's new?"\n>>> q.pub_date\ndatetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)\n\n# Change values by changing the attributes, then calling save().\n>>> q.question_text = "What's up?"\n>>> q.save()\n\n# objects.all() displays all the questions in the database.\n>>> Question.objects.all()\n[<Question: Question object>]\n
\n

ちょっと待ってください。 <Question: Question object>``はこのオブジェクトの表現としてまったく役に立ちません。(``polls/models.py ファイルの中にある) Question``モデルを編集してこれを修正しましょう。:meth:`~django.db.models.Model.__str__` メソッドを``Question と Choice の両方に追加します:

\n
polls/models.py
Code
from django.db import models\nfrom django.utils.encoding import python_2_unicode_compatible\n\n@python_2_unicode_compatible  # only if you need to support Python 2\nclass Question(models.Model):\n    # ...\n    def __str__(self):\n        return self.question_text\n\n@python_2_unicode_compatible  # only if you need to support Python 2\nclass Choice(models.Model):\n    # ...\n    def __str__(self):\n        return self.choice_text\n
\n

あなた自身のインタラクティブシェルでの表示での利便性のためだけではなく、Djangoの自動生成adminでオブジェクトの表現として使用されるという理由からも __str__() メソッドをモデルに追加することは重要です。

\n

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

\n
polls/models.py
Code
import datetime\n\nfrom django.db import models\nfrom django.utils import timezone\n\n\nclass Question(models.Model):\n    # ...\n    def was_published_recently(self):\n        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)\n
\n

import datetime と from django.utils import timezone で Python の 標準モジュール datetime と Django のタイムゾーン関連ユーティリティの django.utils.timezone を参照していることに注意してください。 Python でのタイムゾーンの取り扱いに不慣れな場合は、 タイムゾーンサポートドキュメント </topics/i18n/timezones> を参照してください。

\n

変更を保存して、もう一度 python manage.py shell を実行して新しい Python 対話シェルを始めましょう:

\n
Code
>>> from polls.models import Question, Choice\n\n# Make sure our __str__() addition worked.\n>>> Question.objects.all()\n[<Question: What's up?>]\n\n# Django provides a rich database lookup API that's entirely driven by\n# keyword arguments.\n>>> Question.objects.filter(id=1)\n[<Question: What's up?>]\n>>> Question.objects.filter(question_text__startswith='What')\n[<Question: What's up?>]\n\n# Get the question that was published this year.\n>>> from django.utils import timezone\n>>> current_year = timezone.now().year\n>>> Question.objects.get(pub_date__year=current_year)\n<Question: What's up?>\n\n# Request an ID that doesn't exist, this will raise an exception.\n>>> Question.objects.get(id=2)\nTraceback (most recent call last):\n    ...\nDoesNotExist: Question matching query does not exist.\n\n# Lookup by a primary key is the most common case, so Django provides a\n# shortcut for primary-key exact lookups.\n# The following is identical to Question.objects.get(id=1).\n>>> Question.objects.get(pk=1)\n<Question: What's up?>\n\n# Make sure our custom method worked.\n>>> q = Question.objects.get(pk=1)\n>>> q.was_published_recently()\nTrue\n\n# Give the Question a couple of Choices. The create call constructs a new\n# Choice object, does the INSERT statement, adds the choice to the set\n# of available choices and returns the new Choice object. Django creates\n# a set to hold the "other side" of a ForeignKey relation\n# (e.g. a question's choice) which can be accessed via the API.\n>>> q = Question.objects.get(pk=1)\n\n# Display any choices from the related object set -- none so far.\n>>> q.choice_set.all()\n[]\n\n# Create three choices.\n>>> q.choice_set.create(choice_text='Not much', votes=0)\n<Choice: Not much>\n>>> q.choice_set.create(choice_text='The sky', votes=0)\n<Choice: The sky>\n>>> c = q.choice_set.create(choice_text='Just hacking again', votes=0)\n\n# Choice objects have API access to their related Question objects.\n>>> c.question\n<Question: What's up?>\n\n# And vice versa: Question objects get access to Choice objects.\n>>> q.choice_set.all()\n[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]\n>>> q.choice_set.count()\n3\n\n# The API automatically follows relationships as far as you need.\n# Use double underscores to separate relationships.\n# This works as many levels deep as you want; there's no limit.\n# Find all Choices for any question whose pub_date is in this year\n# (reusing the 'current_year' variable we created above).\n>>> Choice.objects.filter(question__pub_date__year=current_year)\n[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]\n\n# Let's delete one of the choices. Use delete() for that.\n>>> c = q.choice_set.filter(choice_text__startswith='Just hacking')\n>>> c.delete()\n
\n

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

\n
\n
\n

Django Adminの紹介Link to this heading#

\n\n
\n

管理ユーザーを作成するLink to this heading#

\n

まず最初に私達はadminサイトにログインできるユーザーを作成する必要があります。下記のコマンドを実行します:

\n
Shell
$ python manage.py createsuperuser\n
\n

好きなユーザー名を入力しEnterを押してください。

\n
Text
Username: admin\n
\n

希望するemailアドレスを入力するよう促されます:

\n
Text
Email address: admin@example.com\n
\n

最後のステップはパスワードの入力です。2回目のパスワードが1回目と同じことを確認するため、パスワードの入力を2回求められます。

\n
Text
Password: **********\nPassword (again): *********\nSuperuser created successfully.\n
\n
\n
\n

開発サーバーの起動Link to this heading#

\n

Django adminサイトはデフォルトで有効化されます。開発サーバーを起動して探索を始めましょう。

\n

もしサーバーが起動していなかったら、このようにして起動しましょう:

\n
Shell
$ python manage.py runserver\n
\n

次はブラウザを起動して、ローカルドメインの “/admin/” 、つまり http://127.0.0.1:8000/admin/ にアクセスします。以下のような admin のログイ ン画面が表示されるはずです:

\n\"Django\n

:doc:`translation </topics/i18n/translation>`はデフォルトでonになっています。 あなたのブラウザの設定とDjangoの翻訳状況によって、ログインスクリーンはあなたの言語で表示されるかもしれません。

\n
\n
\n

admin サイトに入るLink to this heading#

\n

今回は、前のステップで作成したスーパーユーザーのアカウントでログインを試してみましょう。Django adminのインデックスページが表示されるはずです:

\n\"Django\n

groupsとusersといういくつかのタイプの編集可能なコンテンツが閲覧できるはずです。これらはDjangoに含まれる認証フレームワーク django.contrib.auth によって提供されます。

\n
\n
\n

Poll アプリを admin 上で編集できるようにするLink to this heading#

\n

ところで、 polls アプリはどこにあるんでしょう？ admin のインデクスページを見ても表示されていませんね。

\n

やるべきことは一つです: adminに"Question"オブジェクト達はadmin インタフェースを持つことを伝える必要があります。これを行うために、ファイル polls/admin.py を開いてこのように編集しましょう:

\n
polls/admin.py
Code
from django.contrib import admin\n\nfrom .models import Question\n\nadmin.site.register(Question)\n
\n
\n
\n

admin の機能を探究してみるLink to this heading#

\n

今では私たちが"Question"を登録したので、Djangoはadmin インデクスページにこれを表示すべきだということを知っています:

\n\"Django\n

"Questions"をクリックしましょう。questionsのための"change list"ページが表示されます。このページにはデータベースの中のすべてのquestionsが表示され、あなたはこの中のひとつを変更のために選択することができます。ここに私たちが以前作成した"What's UP?" questionもあります:

\n\"Polls\n

"What's up?" questionを編集するためにクリックしましょう:

\n\"Editing\n

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

\n\n

ページの末尾の部分には操作ボタンがいくつか表示されています:

\n\n

もし「Data published」の値があなたが以前 チュートリアルその1 で作成した questionと一致しないのであれば、それはおそらくあなたが TIME_ZONE で正しい値を設定することを忘れていたことを意味します。これを変更して、ページをリロードし、正しい値が表示されるかチェックします。

\n

「今日」や「現在」ショートカットをクリックして、「Date published」を変更してみましょう。変更したら、「保存して編集を続ける」を押します。次に、右上に ある「履歴 (History)」をクリックしてみましょう。ユーザが管理サイト上でオブジェクトに対して行った変更履歴の全てを、変更時刻と変更を行ったユーザ名付きでリストにしたページが表示されます:

\n\"History\n

モデルのAPIや、あなた自身で親しみやすくしたadmin サイトが方があった方が具合がいいと思うときは、polls アプリにより多くのビュー追加する方法を学習するため チュートリアルその3 を読みましょう。

\n
\n
","rootId":"writing-your-first-django-app-part-2","toc":[{"title":"Database の設定","anchor":"database-setup","children":[]},{"title":"モデルの作成","anchor":"creating-models","children":[]},{"title":"モデルを有効にする","anchor":"activating-models","children":[]},{"title":"API で遊んでみる","anchor":"playing-with-the-api","children":[]},{"title":"Django Adminの紹介","anchor":"introducing-the-django-admin","children":[{"title":"管理ユーザーを作成する","anchor":"creating-an-admin-user","children":[]},{"title":"開発サーバーの起動","anchor":"start-the-development-server","children":[]},{"title":"admin サイトに入る","anchor":"enter-the-admin-site","children":[]},{"title":"Poll アプリを admin 上で編集できるようにする","anchor":"make-the-poll-app-modifiable-in-the-admin","children":[]},{"title":"admin の機能を探究してみる","anchor":"explore-the-free-admin-functionality","children":[]}]}],"breadcrumbs":[{"docname":"intro/index","title":"さぁ始めましょう。","url":"/ja/1.9/intro/"}],"prev":{"docname":"intro/tutorial01","title":"はじめての Django アプリ作成、その 1","url":"/ja/1.9/intro/tutorial01/"},"next":{"docname":"intro/tutorial03","title":"はじめての Django アプリ作成、その 3","url":"/ja/1.9/intro/tutorial03/"},"formats":{"html":"/ja/1.9/intro/tutorial02/","markdown":"/ja/1.9/intro/tutorial02.md","json":"/ja/1.9/intro/tutorial02.json"},"source":"https://github.com/django/django/blob/stable/1.9.x/docs/intro/tutorial02.txt","official":"https://docs.djangoproject.com/ja/1.9/intro/tutorial02/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","fr","ja","id","pt-br","es"]}