LabEx
ログイン登録

データベースのセットアップ

Intermediate

はじめに

このチュートリアルは、「基本的な投票アプリケーションの作成」が終わるところから始まります。データベースをセットアップし、最初のモデルを作成し、Django の自動生成の管理サイトについて簡単に紹介します。

これは Guided Lab です。学習と実践を支援するためのステップバイステップの指示を提供します。各ステップを完了し、実践的な経験を積むために、指示に注意深く従ってください。過去のデータによると、この 中級 レベルの実験の完了率は 65%です。学習者から 100% の好評価を得ています。

データベースのセットアップ

次に、mysite/settings.py を開きます。これは通常の Python モジュールで、Django の設定を表すモジュールレベルの変数があります。

デフォルトでは、設定では SQLite が使用されます。データベースに慣れていない場合、または単に Django を試してみたい場合、これは最も簡単な選択肢です。SQLite は Python に含まれているため、データベースをサポートするために他に何もインストールする必要はありません。ただし、最初の本格的なプロジェクトを始める際には、後々のトラブルを避けるために、PostgreSQL のようなより拡張性の高いデータベースを使用することが望ましい場合があります。

別のデータベースを使用する場合は、適切な「データベースバインディング 」をインストールし、DATABASES の 'default' 項目の次のキーを変更して、データベース接続設定に合わせます。

  • ENGINE <DATABASE-ENGINE> -- 'django.db.backends.sqlite3'、'django.db.backends.postgresql'、'django.db.backends.mysql'、または 'django.db.backends.oracle' のいずれか。他のバックエンドも 利用可能です<third-party-notes>。
  • NAME -- データベースの名前。SQLite を使用する場合、データベースはコンピュータ上のファイルになります。その場合、NAME はそのファイルの完全な絶対パス（ファイル名を含む）にする必要があります。デフォルト値である BASE_DIR / 'db.sqlite3' は、ファイルをプロジェクトディレクトリに保存します。

SQLite 以外のデータベースを使用する場合は、USER、PASSWORD、HOST などの追加設定が必要です。詳細については、DATABASES のリファレンスドキュメントを参照してください。

SQLite 以外のデータベースの場合

SQLite 以外のデータベースを使用する場合は、この時点でデータベースを作成していることを確認してください。データベースの対話型プロンプト内で「CREATE DATABASE database_name;」を使用して行います。

また、mysite/settings.py に記載されているデータベースユーザーが「データベース作成」権限を持っていることも確認してください。これにより、後のチュートリアルで必要になる「テストデータベース 」を自動的に作成できます。

SQLite を使用する場合は、事前に何も作成する必要はありません。データベースファイルは必要になったときに自動的に作成されます。

mysite/settings.py を編集している間、TIME_ZONE を自分のタイムゾーンに設定してください。

また、ファイルの上部にある INSTALLED_APPS 設定にも注目してください。これは、この Django インスタンスでアクティブになっているすべての Django アプリケーションの名前を保持しています。アプリケーションは複数のプロジェクトで使用でき、他の人が彼らのプロジェクトで使用できるようにパッケージ化して配布することができます。

デフォルトでは、INSTALLED_APPS には次のアプリケーションが含まれており、すべて Django に付属しています。

  • django.contrib.admin -- 管理サイト。すぐに使用します。
  • django.contrib.auth -- 認証システム。
  • django.contrib.contenttypes -- コンテンツタイプのフレームワーク。
  • django.contrib.sessions -- セッションフレームワーク。
  • django.contrib.messages -- メッセージングフレームワーク。
  • django.contrib.staticfiles -- 静的ファイルを管理するフレームワーク。

これらのアプリケーションは、一般的なケースの利便性のためにデフォルトで含まれています。

ただし、これらのアプリケーションの一部は少なくとも 1 つのデータベーステーブルを使用しているため、使用する前にデータベースにテーブルを作成する必要があります。そのためには、次のコマンドを実行します。

cd ~/project/mysite
python manage.py migrate

実行する操作:
  すべてのマイグレーションを適用する: admin, auth, contenttypes, sessions
マイグレーションの実行:
  contenttypes.0001_initialを適用中... OK
  auth.0001_initialを適用中... OK
  admin.0001_initialを適用中... OK
  admin.0002_logentry_remove_auto_addを適用中... OK
  admin.0003_logentry_add_action_flag_choicesを適用中... OK
  contenttypes.0002_remove_content_type_nameを適用中... OK
  auth.0002_alter_permission_name_max_lengthを適用中... OK
  auth.0003_alter_user_email_max_lengthを適用中... OK
  auth.0004_alter_user_username_optsを適用中... OK
  auth.0005_alter_user_last_login_nullを適用中... OK
  auth.0006_require_contenttypes_0002を適用中... OK
  auth.0007_alter_validators_add_error_messagesを適用中... OK
  auth.0008_alter_user_username_max_lengthを適用中... OK
  auth.0009_alter_user_last_name_max_lengthを適用中... OK
  auth.0010_alter_group_name_max_lengthを適用中... OK
  auth.0011_update_proxy_permissionsを適用中... OK
  auth.0012_alter_user_first_name_max_lengthを適用中... OK
  sessions.0001_initialを適用中... OK

migrate コマンドは、INSTALLED_APPS 設定を見て、mysite/settings.py ファイルのデータベース設定とアプリケーションに付属しているデータベースマイグレーション（後で説明します）に基づいて、必要なデータベーステーブルを作成します。適用する各マイグレーションについてメッセージが表示されます。興味がある場合は、データベースのコマンドラインクライアントを実行して、\dt（PostgreSQL）、SHOW TABLES;（MariaDB、MySQL）、.tables（SQLite）、または SELECT TABLE_NAME FROM USER_TABLES;（Oracle）を入力して、Django が作成したテーブルを表示してください。

最小構成を好む方へ

前述の通り、デフォルトのアプリケーションは一般的なケースのために含まれていますが、必ずしもすべての人が必要とするわけではありません。必要がない場合は、migrate を実行する前に、INSTALLED_APPS から適切な行をコメントアウトまたは削除しても構いません。migrate コマンドは、INSTALLED_APPS に含まれるアプリケーションのみにマイグレーションを実行します。

モデルの作成

次に、モデルを定義します。基本的には、追加のメタデータ付きのデータベースレイアウトです。

モデルは、データに関する唯一の決定的な情報源です。それは、保存しているデータの必須フィールドと動作を含んでいます。Django は「DRY 原則 」に従っています。目的は、データモデルを 1 か所で定義し、そこから自動的に派生することです。

これにはマイグレーションも含まれます。たとえば、Ruby On Rails とは異なり、マイグレーションは完全にモデルファイルから派生し、本質的には、Django がデータベーススキーマを更新して現在のモデルに合わせるためにロールバックできる履歴です。

投票アプリでは、2 つのモデルを作成します。Question と Choice。Question には質問と公開日があります。Choice には 2 つのフィールドがあります。選択肢のテキストと投票数です。各 Choice は 1 つの Question に関連付けられています。

これらの概念は Python クラスで表されます。polls/models.py ファイルを編集して、以下のようにします。

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

ここでは、各モデルは django.db.models.Model をサブクラス化するクラスで表されています。各モデルには多くのクラス変数があり、それぞれがモデル内のデータベースフィールドを表しています。

各フィールドは ~django.db.models.Field クラスのインスタンスで表されます。たとえば、文字列フィールドの場合は ~django.db.models.CharField、日付時刻の場合は ~django.db.models.DateTimeField です。これにより、Django に各フィールドが保持するデータの型がわかります。

各 ~django.db.models.Field インスタンスの名前（たとえば question_text または pub_date）は、機械が読み取りやすい形式のフィールド名です。Python コードでこの値を使用し、データベースでは列名として使用されます。

~django.db.models.Field には、オプションの最初の位置引数を使用して、人間が読みやすい名前を指定できます。これは、Django のいくつかの内省的な部分で使用され、ドキュメントとしても役立ちます。このフィールドが指定されない場合、Django は機械が読み取りやすい名前を使用します。この例では、Question.pub_date にのみ人間が読みやすい名前を定義しています。このモデルの他のすべてのフィールドについては、フィールドの機械が読み取りやすい名前が人間が読みやすい名前として十分です。

一部の ~django.db.models.Field クラスには必須引数があります。たとえば、~django.db.models.CharField には ~django.db.models.CharField.max_length を指定する必要があります。これは、データベーススキーマだけでなく、検証にも使用されます。これは後で説明します。

~django.db.models.Field にはさまざまなオプション引数もあります。この場合、votes の ~django.db.models.Field.default 値を 0 に設定しています。

最後に、~django.db.models.ForeignKey を使用して関係が定義されていることに注意してください。これにより、Django に各 Choice が 1 つの Question に関連付けられていることがわかります。Django は、多対 1、多対多、1 対 1 のすべての一般的なデータベース関係をサポートしています。

モデルの有効化

この小さなモデルコードは、Django に多くの情報を与えます。これにより、Django は以下のことができます。

  • このアプリケーション用のデータベーススキーマ（CREATE TABLE 文）を作成する。
  • Question と Choice オブジェクトにアクセスするための Python データベースアクセス API を作成する。

しかし、最初に、polls アプリケーションがインストールされていることをプロジェクトに伝える必要があります。

Django アプリケーションは「プラグ可能」です。1 つのアプリケーションを複数のプロジェクトで使用でき、また、特定の Django インストールに束縛される必要がないため、アプリケーションを配布することもできます。

プロジェクトにアプリケーションを含めるには、INSTALLED_APPS 設定にその構成クラスへの参照を追加する必要があります。PollsConfig クラスは polls/apps.py ファイルにあるため、そのドット区切りパスは 'polls.apps.PollsConfig' になります。mysite/settings.py ファイルを編集して、そのドット区切りパスを INSTALLED_APPS 設定に追加します。以下のようになります。

INSTALLED_APPS = [
    "polls.apps.PollsConfig",
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
]

これで Django は polls アプリケーションを含めるようになりました。次に、別のコマンドを実行しましょう。

python manage.py makemigrations polls

以下のような出力が表示されるはずです。

'polls' のマイグレーション:
  polls/migrations/0001_initial.py
    - モデル Question を作成する
    - モデル Choice を作成する

makemigrations を実行することで、Django に対してモデルに変更を加えたこと（この場合は新しいモデルを作成したこと）を伝え、その変更を マイグレーション として保存してもらうように指示しています。

マイグレーションは、Django がモデル（つまりデータベーススキーマ）の変更を保存する方法です。ディスク上のファイルです。新しいモデルのマイグレーションを好きなら読むことができます。それは polls/migrations/0001_initial.py ファイルです。心配しないでください。Django がマイグレーションを作成するたびに読む必要はありませんが、Django が何を変更するかを手動で微調整したい場合には、人間が編集可能なように設計されています。

マイグレーションを実行してデータベーススキーマを自動的に管理するコマンドがあります。それは migrate と呼ばれるもので、すぐに説明しますが、まずは、そのマイグレーションが実行する SQL を見てみましょう。sqlmigrate コマンドはマイグレーション名を引数に取り、その SQL を返します。

python manage.py sqlmigrate polls 0001

以下のような出力が表示されるはずです（読みやすさのために整形しています）。

BEGIN;
--
-- モデル Question を作成する
--
CREATE TABLE "polls_question" (
    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
    "question_text" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
--
-- モデル Choice を作成する
--
CREATE TABLE "polls_choice" (
    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
    "choice_text" varchar(200) NOT NULL,
    "votes" integer NOT NULL,
    "question_id" bigint NOT NULL
);
ALTER TABLE "polls_choice"
  ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"
    FOREIGN KEY ("question_id")
    REFERENCES "polls_question" ("id")
    DEFERRABLE INITIALLY DEFERRED;
CREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");

COMMIT;

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

  • 正確な出力は使用しているデータベースによって異なります。上の例は PostgreSQL 用に生成されています。
  • テーブル名は、アプリケーション名（polls）とモデルの小文字の名前（question と choice）を組み合わせて自動的に生成されます。（この動作をオーバーライドできます。）
  • 主キー（ID）は自動的に追加されます。（これもオーバーライドできます。）
  • 慣例として、Django は外部キーフィールド名に "_id" を付けます。（はい、これもオーバーライドできます。）
  • 外部キー関係は FOREIGN KEY 制約によって明示的になされます。DEFERRABLE の部分は心配しないでください。PostgreSQL に対して、トランザクション終了まで外部キー制約を強制しないように指示しています。
  • 使用しているデータベースに合わせて調整されているため、auto_increment（MySQL）、bigint PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY（PostgreSQL）、または integer primary key autoincrement（SQLite）などのデータベース固有のフィールド型が自動的に処理されます。フィールド名の引用符付けも同様です。たとえば、二重引用符または単一引用符を使用します。
  • sqlmigrate コマンドは実際にはデータベースにマイグレーションを実行しません。代わりに、画面に表示して、Django が必要と思う SQL を見ることができます。Django が何を行う予定かを確認するため、またはデータベース管理者が変更に SQL スクリプトを必要とする場合に便利です。

興味がある場合は、python manage.py check <check> も実行できます。これは、マイグレーションを作成せず、データベースに触れることなく、プロジェクト内の問題をチェックします。

次に、migrate を実行してデータベースにそれらのモデルテーブルを作成しましょう。

python manage.py migrate

実行する操作:
  すべてのマイグレーションを適用する: admin, auth, contenttypes, polls, sessions
マイグレーションの実行:
  polls.0001_initialを適用中... OK

migrate コマンドは、適用されていないすべてのマイグレーション（Django は、データベース内の特殊なテーブル django_migrations を使用して、どのマイグレーションが適用されているかを追跡します）を取得し、データベースに対して実行します。つまり、モデルに加えた変更をデータベース内のスキーマと同期させます。

マイグレーションは非常に強力で、プロジェクトを開発する際に、時間の経過とともにモデルを変更できるようにします。データベースやテーブルを削除して新しく作成する必要がなくなります。ライブでデータベースをアップグレードし、データを失うことなく機能します。このチュートリアルの後半で詳しく説明しますが、今のところ、モデル変更の 3 ステップガイドを覚えておいてください。

  • モデルを変更する（models.py 内）。
  • python manage.py makemigrations <makemigrations> を実行して、それらの変更に対するマイグレーションを作成する。
  • python manage.py migrate <migrate> を実行して、それらの変更をデータベースに適用する。

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

manage.py ユーティリティができることの詳細については、django-admin ドキュメント </ref/django-admin> を参照してください。

API を使ってみる

次に、対話型の Python シェルに入り、Django が提供する無料の API を試してみましょう。Python シェルを起動するには、次のコマンドを使用します。

python manage.py shell

単に「python」と入力する代わりにこれを使用しているのは、manage.py が DJANGO_SETTINGS_MODULE 環境変数を設定するためで、これにより Django に mysite/settings.py ファイルの Python インポートパスがわかります。

シェルに入ったら、データベースAPI </topics/db/queries> を調べてみましょう。

>>> from polls.models import Choice, Question  ## 先ほど書いたモデルクラスをインポートする。

## システムにはまだ質問がありません。
>>> Question.objects.all()
<QuerySet []>

## 新しい質問を作成する。
## デフォルトの設定ファイルではタイムゾーンのサポートが有効になっているため、
## Django は pub_date に tzinfo 付きの datetime を期待します。timezone.now() を使用して
## datetime.datetime.now() の代わりに使用すると、正しい処理が行われます。
>>> from django.utils import timezone
>>> q = Question(question_text="What's new?", pub_date=timezone.now())

## オブジェクトをデータベースに保存する。save() を明示的に呼び出す必要があります。
>>> q.save()

## 今や ID があります。
>>> q.id
1

## Python 属性を介してモデルフィールドの値にアクセスする。
>>> q.question_text
"What's new?"
>>> q.pub_date
datetime.datetime(2023, 9, 7, 1, 18, 48, 335644, tzinfo=datetime.timezone.utc)

## 属性を変更してから save() を呼び出すことで値を変更する。
>>> q.question_text = "What's up?"
>>> q.save()

## objects.all() はデータベース内のすべての質問を表示する。
>>> Question.objects.all()
<QuerySet [<Question: Question object (1)>]>

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

from django.db import models


class Question(models.Model):
    #...
    def __str__(self):
        return self.question_text


class Choice(models.Model):
    #...
    def __str__(self):
        return self.choice_text

モデルに ~django.db.models.Model.__str__ メソッドを追加することは重要です。対話型プロンプトを扱う際に自分自身の利便性のためだけでなく、Django の自動生成の管理サイト全体でオブジェクトの表現が使用されるためです。

このモデルにカスタムメソッドも追加しましょう。

import datetime

from django.db import models
from django.utils import timezone


class Question(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.utils.timezone 内の Django のタイムゾーン関連のユーティリティを参照するために使用されます。Python でのタイムゾーンの処理に慣れていない場合は、タイムゾーンサポートドキュメント </topics/i18n/timezones> で詳しく学ぶことができます。

これらの変更を保存し、再度 python manage.py shell を実行 して新しい Python 対話型シェルを起動します。

>>> from polls.models import Choice, Question

## 私たちの__str__() の追加が機能したことを確認する。
>>> Question.objects.all()
<QuerySet [<Question: What's up?>]>

## Django はキーワード引数によって完全に駆動される豊富なデータベース検索 API を提供しています。
>>> Question.objects.filter(id=1)
<QuerySet [<Question: What's up?>]>
>>> Question.objects.filter(question_text__startswith="What")
<QuerySet [<Question: What's up?>]>

## 今年公開された質問を取得する。
>>> from django.utils import timezone
>>> current_year = timezone.now().year
>>> Question.objects.get(pub_date__year=current_year)
<Question: What's up?>

## 存在しない ID を要求すると、例外が発生します。
>>> Question.objects.get(id=2)
Traceback (most recent call last):
 ...
DoesNotExist: Question matching query does not exist.

## 主キーによる検索は最も一般的なケースなので、Django は主キーの完全一致検索用のショートカットを提供しています。
## 以下は Question.objects.get(id=1) と同じです。
>>> Question.objects.get(pk=1)
<Question: What's up?>

## 私たちのカスタムメソッドが機能したことを確認する。
>>> q = Question.objects.get(pk=1)
>>> q.was_published_recently()
True

## この質問にいくつかの選択肢を与える。create 呼び出しは新しい
## Choice オブジェクトを構築し、INSERT 文を行い、利用可能な選択肢のセットに選択肢を追加し、新しい Choice オブジェクトを返します。Django は
## 外部キー関係の「他方」（たとえば質問の選択肢）を保持するセットを作成し、API を介してアクセスできます。
>>> q = Question.objects.get(pk=1)

## 関連オブジェクトセットからの選択肢を表示する -- 今のところはありません。
>>> q.choice_set.all()
<QuerySet []>

## 3 つの選択肢を作成する。
>>> q.choice_set.create(choice_text="Not much", votes=0)
<Choice: Not much>
>>> q.choice_set.create(choice_text="The sky", votes=0)
<Choice: The sky>
>>> c = q.choice_set.create(choice_text="Just hacking again", votes=0)

## Choice オブジェクトは関連する Question オブジェクトに API アクセスを持っています。
>>> c.question
<Question: What's up?>

## 逆も同様です。Question オブジェクトは Choice オブジェクトにアクセスします。
>>> q.choice_set.all()
<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>
>>> q.choice_set.count()
3

## API は必要な限り関係を自動的に辿ります。
## 関係を区切るには 2 つのアンダースコアを使用します。
## これは必要なだけ深く機能します。制限はありません。
## 今年の公開日付を持つ任意の質問のすべての選択肢を見つける
## （上で作成した'current_year'変数を再利用）。
>>> Choice.objects.filter(question__pub_date__year=current_year)
<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>

## 選択肢の 1 つを削除しましょう。delete() を使用します。
>>> c = q.choice_set.filter(choice_text__startswith="Just hacking")
>>> c.delete()

モデル関係の詳細については、関連オブジェクトのアクセス </ref/models/relations> を参照してください。APIを介してフィールド検索を行う際の2つのアンダースコアの使用方法については、フィールド検索 <field-lookups-intro> を参照してください。データベースAPIの詳細については、データベース API リファレンス </topics/db/queries> を参照してください。

Django 管理サイトの紹介

スタッフやクライアントにコンテンツを追加、変更、削除させるための管理サイトを生成するのは、創造性を必要としない退屈な作業です。そのため、Django はモデルの管理インターフェイスの作成を完全に自動化しています。

Django はニュース編集室の環境で書かれ、「コンテンツ提供者」と「一般公開」サイトの間に非常に明確な区別があります。サイト管理者はシステムを使ってニュース記事、イベント、スポーツのスコアなどを追加し、そのコンテンツが一般公開サイトに表示されます。Django は、サイト管理者がコンテンツを編集するための統一インターフェイスを作成する問題を解決します。

管理サイトはサイト訪問者には使用される意図がありません。サイト管理者向けのものです。

管理ユーザーの作成

まず、管理サイトにログインできるユーザーを作成する必要があります。次のコマンドを実行します。

python manage.py createsuperuser

好きなユーザー名を入力して Enter キーを押します。

ユーザー名: admin

次に、好きなメールアドレスを入力するように促されます。

メールアドレス: admin@example.com

最後のステップはパスワードを入力することです。パスワードを 2 回入力するように求められ、2 回目は 1 回目の確認として使用されます。

パスワード: 12345678
パスワード (再入力): 12345678

このパスワードは一般的すぎます。
このパスワードは完全に数字のみです。
パスワード検証をバイパスしてユーザーを作成しますか？ [y/N]: y
スーパーユーザーが正常に作成されました。

開発サーバーを起動する

Django 管理サイトはデフォルトで有効になっています。開発サーバーを起動して確認しましょう。

サーバーが実行されていない場合は、次のように起動します。

python manage.py runserver

次に、VNC タブでウェブブラウザを開き、ローカルドメインの "/admin/" にアクセスします。たとえば、http://127.0.0.1:8000/admin/。管理サイトのログイン画面が表示されるはずです。

Django 管理サイトのログイン画面

デフォルトでは 翻訳 </topics/i18n/translation> が有効になっているため、LANGUAGE_CODE を設定すると、ログイン画面が指定された言語で表示されます（Django に適切な翻訳がある場合）。

管理サイトにログインする

次に、前の手順で作成したスーパーユーザーアカウントでログインしてみましょう。Django 管理サイトのインデックスページが表示されるはずです。

Django 管理サイトのインデックスページ

編集可能なコンテンツのいくつかの種類が表示されるはずです。グループとユーザーです。これらは、Django に付属する認証フレームワークである django.contrib.auth によって提供されています。

投票アプリを管理サイトで編集可能にする

では、私たちの投票アプリはどこにあるのでしょうか？管理サイトのインデックスページには表示されていません。

もう 1 つやることがあります。管理サイトに対して、Question オブジェクトに管理インターフェイスがあることを伝える必要があります。このために、polls/admin.py ファイルを開き、以下のように編集します。

from django.contrib import admin

from.models import Question

admin.site.register(Question)

無料の管理機能を試す

Question を登録したので、Django はそれが管理サイトのインデックスページに表示されるべきであることを知っています。

Django 管理サイトのインデックスページ、今は投票アプリが表示されます

「質問」をクリックします。すると、質問の「変更一覧」ページに移動します。このページにはデータベース内のすべての質問が表示され、変更する質問を選ぶことができます。先ほど作成した「What's up?」の質問があります。

投票アプリの変更一覧ページ

「What's up?」の質問をクリックして編集します。

投票質問を編集する

ここで注目すべきことは以下の通りです。

  • フォームは自動的に Question モデルから生成されます。
  • 異なるモデルフィールド型（~django.db.models.DateTimeField、~django.db.models.CharField）は適切な HTML 入力ウィジェットに対応しています。各フィールド型は、Django 管理サイトで自身をどのように表示するかを知っています。
  • 各 ~django.db.models.DateTimeField には無料の JavaScript ショートカットがあります。日付には「今日」のショートカットとカレンダーポップアップがあり、時刻には「今」のショートカットと一般的に入力される時刻をリスト表示する便利なポップアップがあります。

ページの下部にはいくつかのオプションがあります。

  • 保存 -- 変更を保存して、この種のオブジェクトの変更一覧ページに戻ります。
  • 保存して続けて編集 -- 変更を保存して、このオブジェクトの管理ページを再読み込みします。
  • 保存して新しいものを追加 -- 変更を保存して、この種のオブジェクト用の新しい空白のフォームを読み込みます。
  • 削除 -- 削除確認ページを表示します。

「公開日付」の値が 基本的な投票アプリケーションの作成 で質問を作成した時刻と一致しない場合、おそらく TIME_ZONE 設定の正しい値を設定するのを忘れていることが原因です。設定を変更し、ページを再読み込みして、正しい値が表示されることを確認してください。

「今日」と「今」のショートカットをクリックして「公開日付」を変更します。その後、「保存して続けて編集」をクリックします。そして、右上の「履歴」をクリックします。このオブジェクトに対して Django 管理サイトを介して行われたすべての変更がタイムスタンプと変更を行ったユーザー名とともに一覧表示されるページが表示されます。

質問オブジェクトの履歴ページ

モデル API に慣れ、管理サイトに慣れたら、公開インターフェイスビューの作成 を読んで、投票アプリにさらに多くのビューを追加する方法を学びましょう。

まとめ

おめでとうございます！データベースのセットアップの実験を完了しました。さらにスキルを向上させるために、LabEx でさらに多くの実験を行って練習してください。