Djangoでウェブアプリを作る(8) – モデルを有効にする

今回は、モデルを有効にする・・ということで、モデル作成後に、まだ、何かいじらなければならないようだ。

スポンサードリンク

SQL文は書かなくてよいらしい・・

うーむ・・わずかなコードを書くだけでDjangoが察してくれるというのは、何となく分かるが・・

データベースの「スキーマ」とは ” データベースの構造を表現する設計図 ” ・・つまり、データベースを作る時にわざわざSQL文を書く必要が無い、ということのようだ。

データベースAPIを作成できる・・

SQLiteでデータベースを操作する時はSQL文を書く必要があるが、大抵は、DatabaseManagerクラスのような形でAPIを自前で書いていた。その部分をDjangoが自動で作ってくれるということだな。

そこは自動でやってくれないのか・・

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

えーと・・　pollsアプリケーションを作成しただけでは、Django側は、アプリを認識できないということなのか？

アプリケーションをプロジェクトに含めるには、構成クラスへの参照を INSTALLED_APPS 設定に追加する必要があります。

・・・INSTALLED_APPSというのはどこだ？　ああ、mysite/settings.py の中にある。

mysite/settings.py

# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

ここに構成クラスの参照を追加・・・何、構成クラスって？

チュートリアルのコードには、一行追加されてるな・・・

mysite/settings.py

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

” polls.apps.PollsConfig ” が構成クラスということか？

PollsConfig クラスは、 polls/apps.py にあるので、ドットつなぎのパスは ‘polls.apps.PollsConfig’ となります。

polls/apps.pyって初めて開くな。

あ、自動でPollsConfigクラスが定義されてる。中身は意味不明だが・・・

polls/apps.py

from django.apps import AppConfig

class PollsConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'polls'

とりあえず、プロジェクト内でアプリケーションを作成すると、この構成クラスとやらが、apps.pyに自動で定義される。それを手動でsettings.py の ” INSTALLED_APPS ” に追加しろ・・・ということでいいのでしょうか？

どうせなら、ここまで自動化出来んのか？

コマンド ” makemigrations “

さて、これでpollsアプリケーションが認識できるらしい。

プロンプトで以下のコマンドを実行。

python manage.py makemigrations polls

実行後、次のような表示が・・

C:\django_project\mysite>python manage.py makemigrations polls

Migrations for 'polls':
  polls\migrations\0001_initial.py
    - Create model Question
    - Create model Choice

mysite/polls/migrationsフォルダ内に0001_initial.pyが作成されている。

中身はこんな感じだ。

mysite/polls/migrations/001_initial.py

# Generated by Django 3.2.6 on 2021-08-22 08:34

from django.db import migrations, models
import django.db.models.deletion

class Migration(migrations.Migration):

    initial = True

    dependencies = [
    ]

    operations = [
        migrations.CreateModel(
            name='Question',
            fields=[
                ('id', models.BigAutoField(auto_created=True, primary_key=True, 
                serialize=False, verbose_name='ID')),
                ('question_text', models.CharField(max_length=200)),
                ('pub_date', models.DateTimeField(verbose_name='date published')),
            ],
        ),
        migrations.CreateModel(
            name='Choice',
            fields=[
                ('id', models.BigAutoField(auto_created=True, primary_key=True, 
                serialize=False, verbose_name='ID')),
                ('choice_text', models.CharField(max_length=200)),
                ('votes', models.IntegerField(default=0)),
                ('question', 
                models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, 
                to='polls.question')),
            ],
        ),
    ]

何となく、SQL文に渡して、データベースにテーブルを作ってるような感じだな・・

マイグレーション(migration)を直訳すると「移転」を意味する。

Djangoでは、モデル(データベースの設計図)に変更があった場合、マイグレーションという単位で変更履歴を保存するらしい。

データベースの設計は、そんなに変更する機会は無いような気もするが・・・何か、使う場面があるのだろうか？

コマンド ” sqlmigrate “

マイグレーションがどんなSQLを実行するのか見てみましょう。 sqlmigrate コマンドはマイグレーションの名前を引数にとってSQLを返します:

マイグレーションが、どうやってデータベースにアクセスしているか、変換後のSQL文を見ていこう。次のコマンドを実行してみる。

python manage.py sqlmigrate polls 0001

ああ、マイグレーションがSQL文に変換された。

なるほど、実際はこんな感じでSQL文に変換されてデータベースにテーブルを定義しているのだな。

C:\django_project\mysite>python manage.py sqlmigrate polls 0001

BEGIN;
--
-- Create model Question
--
CREATE TABLE "polls_question" (
    "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, 
    "question_text" varchar(200) NOT NULL, 
    "pub_date" datetime NOT NULL);
--
-- Create model Choice
--
CREATE TABLE "polls_choice" (
    "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, 
    "choice_text" varchar(200) NOT NULL, 
    "votes" integer NOT NULL, 
    "question_id" bigint NOT NULL
    REFERENCES "polls_question" ("id") 
    DEFERRABLE INITIALLY DEFERRED);

CREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");

COMMIT;

あれ・・・チュートリアルの実行例とちょっと違うな・・

因みに、チュートリアルでは次のような感じだ。

BEGIN;
--
-- Create model Question
--
CREATE TABLE "polls_question" (
    "id" serial NOT NULL PRIMARY KEY,
    "question_text" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
--
-- Create model Choice
--
CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "choice_text" varchar(200) NOT NULL,
    "votes" integer NOT NULL,
    "question_id" integer 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;

チュートリアルのドキュメントバージョンは3.2、Djangoのバージョン3.2.6なので、どちらも最新のはずだが・・・

ここは、なぜこうなっているのか不明。あまり、深入りすると足踏み状態になりそうだ。エラーが出ているわけではないので、とりあえずスルーしておこう。

コマンド ” migrate “

モデル(データベース設計)を変更する時は、次の３ステップが必要のようだ。

ここで注意点。チュートリアルでは、サラッと次のような一文がある。

sqlmigrate コマンドは実際にはデータベースにマイグレーションを実行しません。ただ、Djangoが必要としているSQLが何であるかをスクリーンに表示するだけです。

” sqlmigrate “　と　” migrate ” という二つのコマンドがあり、モデルを実際に適応するのは、” migrate ” の方だ。(これを見過ごして次回ミスを犯すことに・・)

migrateコマンドはすべての適用されていないマイグレーションを捕捉してデータベースに対してそれを実行します。

では、コマンドプロンプトでmigrateコマンドを実行して、定義したモデルをデータベースに反映させておこう。

C:\django_project\mysite>python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying polls.0001_initial... OK
  Applying sessions.0001_initial... OK

C:\django_project\mysite>

これで、いいんだよな？

ああ、確かにデータベースファイル(db.sqlite3)が生成されてるな。

ところで、.idea と__pycache__ というフォルダがいつの間にかあるんだが、これ何だろう？

.ideaフォルダは、Pychameで今回のプロジェクトを読み込んだ時に自動生成されたようだ。今回は開発環境は使わないので削除しておく。

__pychache__は、コンパイルされたコードがまとめられている。毎回、実行時に再コンパイルしなくてもよいように勝手に作るらしい。削除してもまた勝手に生成されるだろう。