Django REST Framework（DRF）って何？

「Django」は Python で Webアプリケーションを作成するためのフレームワークで、Webアプリケーションを作成する際に必要となるコンポーネント（部品）や API を多数提供しています。Django は多数の機能を提供しているものの、REST API バックエンド（REST API を提供する Webアプリケーション）を構築する際のさまざまなニーズに応えるには少し機能が足りず、いろいろと自前で実装しなければいけません。

そこで登場したのが、「Django REST Framework」（以降「DRF」と表記）です。DRF は、REST API バックエンドを構築することに特化したサードパーティ製の Django パッケージで、REST API を提供する際に必要となる機能や便利な機能を補完・拡充してくれる拡張パックのような役割を果たします。実際のプロジェクトでは、Webアプリケーションのベースとなる機能は Django を利用し、REST API に特化した機能は DRF を利用する、といった使い方をします。

DRF 本を書いた理由

かく言う私も現在仕事で「DRF」を使っており、仕事の現場においては「素の Django」よりも「DRF」の方が使われているようにも感じています。しかしながら、DRF に関する日本語情報は Django よりも圧倒的に不足しています。日本語書籍については現在どこを探しても見つかりません。商業誌を待っていてもあと何年かは出ないだろうから、もし技術書典6に当選したら30ページくらいの本当に薄い本を書いてみようかなと思い立ったのが昨年末。これが地獄の始まりでした。。

それからどうなったか？

技術書典4から3回連続で技術同人誌を頒布していますが、今回が一番辛かったです。昨年末あたりから執筆のための調査を始めていて実質的な執筆は2月から開始したのですが、あれよあれよという間に30ページが50ページになり、70ページになり、最終的には表紙を含めて128ページの「薄くない本」に仕上がってしまったのでした。

毎回執筆内容を Git で管理していて今回からコミットコメントに執筆時間を加えることにしてみたのですが、今回の合計執筆時間は333時間になりました（会場価格は1,000円なので私の作業1時間あたり「3円」で買えてしまうということですね・・）。内容には満足しているものの、3月は生活のすべてを投げ打って執筆に没頭してしまいました。ご迷惑をお掛けした関係各所の皆さま、本当に申し訳ありませんでした。最後に、家族のサポートがなければこの本は世に出ていなかったということも付け加えさせてください。

どんな内容？

Django REST Framework（DRF）を現場で使う際に必要となる基礎知識についてまとめた技術同人誌で、本文124ページ、まるまる「Django REST Framework」に関する本です。なお、DRF は Django をベースにしている部分があるので Django についての解説は要所要所で書いているものの、Python についての解説は一切ありませんのでご注意ください。

前半は DRF の概要や全体像、コンポーネントごとの仕組みや使い方、セキュリティや認証などの基礎知識を座学で進めていきます。後半はチュートリアルおよび発展的な Tips という構成になっています。

後半のチュートリアルでは、Django も Django REST Framework も何にも分からないという方でもちょっとした SPA が作れるように、Django REST Framework と Vue.js を使った SPA のサンプルプロジェクトを2つ、簡単なものと少し難しめなものを用意しました。これを手本に写経すれば、REST API を使った Webアプリケーションの仕組みが何となく掴めるでしょう。

レビュアーとして、くろのて勉強会を主催をしている @crohacoさんにもご協力いただいたのですが、@crohaco さんからお墨付きをいただけました。DRF の勉強会ではお世話になりました。そしてレビューありがとうございました。

本のレビューをさせてもらいましたが、DRFやってる人、これからやる人は絶対読んだほうがいいです❗️
4/14 お忘れなく😆 https://t.co/TiXrZjHUJV

— くろ (@crohaco) 2019年4月10日

そのほか、Django 系イベントでいつも会う @kaizumakiさんや u1 さんにもレビューをしていただきました。ありがとうございました！

対象読者

対象読者としては、

• Django は何となく分かるが、Django REST Framework は初めてという方
• Django REST Framework のまとまった日本語情報を手に入れたい方
• Django REST Framework ＋ Vue.js で SPA を構築したい方
• 現場で本格的に Django REST Framework を使いたい方

を想定しています。

最低限必要の知識としては「Django の仕組みが何となく理解できていること」です。Django 公式チュートリアルや Django Girls チュートリアルをひと通り終えたくらいであれば、何とか理解できるレベルになっているかと思います。拙著『現場で使える Django の教科書《基礎編》』を読み終えたくらいの知識があれば万全ですが、『現場で使える Django の教科書《実践編》』レベルの知識は不要でしょう。

現場で使える Django の教科書《基礎編》

• 作者:横瀬明仁
• 出版社/メーカー: NextPublishing Authors Press
• 発売日: 2018/08/26
• メディア:オンデマンド (ペーパーバック)
• この商品を含むブログを見る

現場で使える Django の教科書《実践編》

• 作者:横瀬明仁
• 発売日: 2018/12/08
• メディア: Kindle版
• この商品を含むブログを見る

目次

気になる目次は ↓ のようになっています。

頒布本情報

当日のお品書きを作りました。
お釣りがなるべく出ないように考慮した「会場特別価格」です。

あと、既刊の『現場で使える Django の教科書《基礎編》』『現場で使える Django の教科書《実践編》』も持っていきます。

これらの既刊については、Amazon や BOOTH で電子版とペーパー版が絶賛販売中です。

◆ 現場で使える Django の教科書《基礎編》 - Amazon（電子版・ペーパー版）

現場で使える Django の教科書《基礎編》

• 作者:横瀬明仁
• 発売日: 2018/08/21
• メディア: Kindle版
• この商品を含むブログを見る

◆ 現場で使える Django の教科書《実践編》 - Amazon（電子版）

現場で使える Django の教科書《実践編》

• 作者:横瀬明仁
• 発売日: 2018/12/08
• メディア: Kindle版
• この商品を含むブログを見る

◆ 現場で使える Django の教科書《実践編》 - BOOTH（ペーパー版）
現場で使える Django の教科書《実践編》【紙の本】（技術書典5バージョン） - あきよこブログ（akiyoko - BOOTH

頒布場所

頒布場所は「か63」の「あきよこブログ」です。
見本誌を置いてますので、立ち読みだけでもお気軽にどうぞ。

池袋サンシャインシティ2F、4/14（日） 11時オープンです。今回は、会場2時間は有料入場券（1,000円）が必要になっています。それでも午前中は混雑すると思いますのでご注意ください。

なお勝手ながら、当日13時までの有料入場者特典として、弊ブースにて『現場で使えるDjangoの教科書《実践編》』（紙の本）を会場特別価格からさらに500円引きさせていただきます（1,500円→1,000円）。（後払いアプリだと対応できないかもしれないので）現金払いのみでの割引とさせてください。

技術書典6の有料入場者特典！！

【か63 あきよこブログ】にて、当日13時まで『現場で使えるDjangoの教科書《実践編》』（紙の本）を会場特別価格からさらに500円引きします（1,500円→1,000円）https://t.co/dTFg6uJO6U

おいでませ～😉#技術書典#有料入場者特典pic.twitter.com/isnYy0M4vd

— akiyoko /か63@技術書典6/「現場で使えるDjangoの教科書」販売中 (@aki_yok) 2019年4月11日

最後に

ウチの奥さんに「そんなに寝てないと死ぬよ？」と何度も言われながら、ようやく今週の火曜にすべり込み入稿できました。表紙がモノクロだったので標準価格からのアップは免れましたが、カラーだったらアウトというギリギリっぷりでした。そんな感じで今回の執筆で気力体力ともに尽き果てました。今日の技術書典が終わったら昇天しているかもしれません。。

発表の動機

仕事の現場でもっと Django を使ってほしいという想いから、この発表を思い立ちました。Django 普及の突破口のひとつとして、まずはセキュリティの懸念を取り払うことが重要なのでは？と考えたのです。

Python が企業でも幅広く使われるようになったことや書籍が充実し始めたことで、日本でもようやく Django が注目されるようになりました。4月に待望のバージョン2系の LTS がリリースされ、ますます現場で Django が盛り上がることが予想されますが、導入検討の際にネックになるもののひとつに「セキュリティ」への懸念があります。私は現在、ある Django プロジェクトの立ち上げに携わっているのですが、そこで実際によく言われたのが「Django ってセキュリティ的にどうなん？」でした。日本では（特に SIer 界隈では）Django がまだあまり知られていないので、そのような疑問が出てくるのは当然といえば当然かもしれません。

一方の開発者からすると、フルスタック（全部入り）の Django にはデフォルトでセキュリティ対策も含まれていますが、そのあたりの理解が中途半端だと、リリースした Webアプリケーションが悪意ある攻撃者の格好の餌食になってしまいかねません。そうならないためにも、Django のセキュリティ事情については開発前から（もちろん開発中でも）きちんと把握しておきたいところです。

そこで今回、IPA（情報処理推進機構）が注意喚起情報として公表している「安全なウェブサイトの作り方」という冊子にまとめられた代表的な脆弱性の概要と、それらの脆弱性に対して Django では具体的にどのような対策をしているのかについて解説することにしました。これによって発注側企業においてはセキュリティの懸念が払拭され、一方の開発側企業においてはセキュリティ施策のヒントとして活用されることを期待しています。

対象者

対象者は、Django の導入を検討している方、および Django を使った Webアプリケーション開発者を想定しています。なお、Django 初級者の方にも十分理解できる内容になっていると思います。

Webアプリケーションの基本的な知識（特に Cookie を使ったセッション管理や HTTPヘッダなどの知識）があれば、セキュリティの知識についてはほぼゼロ（用語を何となく聞いたことがあるレベル）でも問題ありません。CSRF などの重要な、そして重要な割にあまりよく理解されていないものについては、「CSRF（しーさーふ）って何？」というレベルの人にも分かるように基本から解説しています。

ポイント

メインの話題として

① Webアプリケーションのセキュリティ対策ってそもそも必要なの？
② 「これだけは絶対やっとけ」的な基準はある？
③ フルスタック（全部入り）の Django を使えばセキュリティ対策もまるっと万事解決？

の三点について話しました。
詳細についてはスライドをご覧ください。

発表の準備

昨年の LTでド緊張して失敗した苦い思い出があるので、今回はまず、心構えから入りました。事前に読んだのは、たまたま見つけた オリラジ中田さんの講演会ログです。要約すると、プレゼンでは「カンペを読まない」「言い訳しない」「練習をサボらない」の3つのタブーがあるということです。中でも、人前で練習をすることが「練習」でそれ以外は「練習」ではないというのはまさにその通りだと思い、リハーサルをなるべく多くこなそうと考えていました。

発表の内容については CFP を出した頃に目次レベルまで固めていたのですが、実際に発表資料を準備し始めたのは仕事の関係もあって GW の終盤からとなりました。しかしこれはちょっと遅すぎました。資料が完成したのは本番５日前。そこから２回、会社の Django 経験者やコンサルタントのメンバーの前、そして現プロジェクトメンバーの前でのリハーサルをおこないました。メンバーからのフィードバック、そして自身の反省から、資料がブラッシュアップされていき、話した方がよいこと・話さなくてよいことが明確になり、想定問答も明らかになって私にとっては良いこと尽くめでした。もっとリハーサルをしたかったのですが、何度も集まってもらうのもメンバーの負担になるのと、直前にフィードバックをもらっても反映できない、余計に混乱してしまうと感じたので、これが限界だったのかも知れません。あとはブツブツ独り言を繰り返し、本番の流れをイメージしていきました。

フィードバックの中で、「図を指差しで説明するよりもレーザーポインターでやった方がいい」と言われて急遽買ったのがこれ。パワポのページ送りもできます。本番前日の夕方に届きました。しかしこれが、当日あのような事件を引き起こすことになろうとは。。

LNGOOR ワイヤレス プレゼンター レーザーポインター PPTスライド用リモート USB充電式 リモートコントロール ワイヤレスマウス操作 PowerPoint、Keynote、Googleスライド用リモート等対応 収納パック付き(ブラック)

• 出版社/メーカー: LNGOOR
• メディア:オフィス用品
• この商品を含むブログを見る

あと、GW 中盤に引いた風邪がずっと長引いていたので体調を整えるために前日夜にマッサージに行ったのですが、強かったのか余計に首を痛めてしまいました。

発表はどうだった？

「発表前にやることリスト」を作っていたので、それを淡々とこなすことで緊張はギリギリのところで抑えられていました。

しかし、プレゼン開始直後に事件が起きました。前日の動作チェックでは問題なかったレーザーポインターがページ送りができなくなり、直前に使用を諦めました。これで緊張のコップから水が少し溢れてしまいました。。

この事件がきっかけとなって冒頭の10分はガチガチでした。途中からあきらめの境地に至ってから割と話せるようになったと思いますが、そこで何とか踏み止まれたのも事前のリハーサルのおかげです。あれが無ければもうボロボロの結果になったに違いありません。協力してくださった皆さん、本当にありがとうございました。

session 2
Room 1 現場で使えるDjangoのセキュリティ対策／Akihito Yokose#djangocongress#サイボウズpic.twitter.com/aVrSsqKhsY

— C.KaeDe (@chigusa_kaede) 2019年5月18日

質問

想定よりも時間がかかってしまいましたが、発表は42分頃に終わりました。そこで出た質問について補足します。

反響

いろいろと反響をいただきましたが、一番驚いたのがこれです。

“現場で使える Django のセキュリティ対策 / Django security measures for business (DjangoCon JP 2019) - Speaker Deck” https://t.co/RVDhmEMIUb

— 徳丸 浩 (@ockeghem) 2019年5月18日

あの徳丸さんにTweetしてもろた！😲マジか！

徳丸さんは、私の発表でも紹介した Webアプリのセキュリティ対策の金字塔「徳丸本」こと『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版』の著者です。現場でも必読書になっています。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版［リフロー版］　脆弱性が生まれる原理と対策の実践

• 作者:徳丸浩
• 出版社/メーカー: SBクリエイティブ
• 発売日: 2018/09/20
• メディア: Kindle版
• この商品を含むブログを見る

あと夕方頃に気付いたのがこちら。Speaker Deck のスライド資料が、はてなブックマークのホットエントリーに入っていたみたいです。

今日の DjangoCongress で発表したスライド資料が、はてなブックマークのホットエントリーに入ったみたいです 😆https://t.co/h1UAytQmED#djangocongresspic.twitter.com/1RmtvwABh9

— akiyoko /「現場で使えるDjangoの教科書」販売中 (@aki_yok) 2019年5月18日

最後に

今年の DjangoCongress JP 2019（Day 1 カンファレンスデー）はセッションもパーティーも大盛況で、大御所イベントのような安定感がありました。これも、ずっと前からこの日のために動いてくれていたスタッフの皆さんの準備、運営、そして情熱のおかげです。本当にありがとうございました。昨年も参加させていただき、そして今年はセッション発表の機会をいただいて、このような素晴らしい場で発表側に回れたことは大変光栄に感じています。おかげさまで昨年のリベンジもできました。またたくさんの方にセッションを聴きに来ていただき、嬉しくそして心強かったです。機会があれば来年もチャレンジしてみたいと思います。

Django の薄い同人誌3冊の見本誌を会場に持っていっているので、興味ある方はお声掛けください。

今日は直接販売はしませんが、最後のじゃんけん大会に何冊か提供していますのでぜひご参加を😊#djangocongresspic.twitter.com/puWk8Uyx1y

— akiyoko /「現場で使えるDjangoの教科書」販売中 (@aki_yok) 2019年5月18日

ビアパーティーのピンチョス！#djangocongresspic.twitter.com/Eqi38ICj4U

— akiyoko /「現場で使えるDjangoの教科書」販売中 (@aki_yok) 2019年5月18日

おまけ

じゃんけん大会で一番人気だった『現場で使える Django REST Framework の薄い本』は、BOOTH というオンラインショップから購入可能です（紙の本のみ）。

akiyoko.booth.pm

DjangoCongress に来るくらいの人はもうほとんど持ってる or 知ってるという噂もありますが（笑）、『現場で使える Django の教科書』シリーズ（基礎編・実践編）も BOOTH で購入できます。

akiyoko.booth.pm

『現場で使える Django の教科書』シリーズ（基礎編・実践編）は、Amazon でも販売しています（電子版もあり）。

現場で使える Django の教科書《基礎編》

• 作者:横瀬明仁
• 出版社/メーカー: NextPublishing Authors Press
• 発売日: 2018/08/26
• メディア:オンデマンド (ペーパーバック)
• この商品を含むブログを見る

現場で使える Django の教科書《実践編》

• 作者:横瀬明仁
• 発売日: 2018/12/08
• メディア: Kindle版
• この商品を含むブログを見る

どんな内容？

技術書典6 で頒布した前作『現場で使える Django REST Framework の薄い本』にかなり大幅な加筆・改訂を加えて、「Django の教科書」シリーズとしてリニューアルしました。前作の124ページに対して、今作は204ページと大ボリュームの仕上がりになっています。

今のところ、同人誌を含めて 日本でオンリーワンの「Django REST Framework」の日本語書籍になっています。

内容は、Django REST Framework を現場で使う際に必要となる基礎知識と発展的な Tips をまとめたものになっています。なお、Django REST Framework は Django をベースにしている部分があるので、Django についての解説に紙面を割いているところもあります。

前半は DRF の概要や全体像、コンポーネントごとの仕組みや使い方、セキュリティや認証などの基礎知識を座学で進めていきます。後半はチュートリアルおよび発展的な Tips という構成になっています。

後半のチュートリアルでは、Django も Django REST Framework も何にも分からないという方でもちょっとした SPA が作れるように、Django REST Framework と Vue.js を使った SPA のサンプルプロジェクトを2つ、簡単なものと少し難しめなものを用意しました。これを手本に写経すれば、REST API を使った Webアプリケーションの仕組みが何となく掴めるでしょう。

目次

対象読者

対象読者としては、

• Django は何となく分かるが、Django REST Framework は初めてという方
• Django REST Framework のまとまった日本語情報を手に入れたい方
• Django REST Framework ＋ Vue.js で SPA を構築したい方
• 現場で本格的に Django REST Framework を使いたい方

を想定しています。

最低限必要の知識としては「Django の仕組みが何となく理解できていること」です。Django 公式チュートリアルや Django Girls チュートリアルをひと通り終えたくらいであれば、何とか理解できるレベルになっているかと思います。拙著『現場で使える Django の教科書《基礎編》』を読み終えたくらいの知識があれば万全ですが、『現場で使える Django の教科書《実践編》』レベルの知識は不要でしょう。

前作の薄い本と何が違うの？

ざっと挙げるとこんな違いがあります。

• 本文が204ページに大幅増（前作の124ページから1.6倍！）
• DRF のコンポーネントの解説が充実
• ユニットテストの章を新設
• Tips（発展編）のトピック数が 5 ⇒ 13 に（ページ数は 11p ⇒ 31p）
• 各種ライブラリは最新バージョンに対応

一番の特徴は、コンポーネントの解説を充実させたことです。「モデル・シリアライザ・ビュー・URLconf」で1つの章になっていたのを、それぞれ独立した章として新設しました。ページ数では、モデル 1p ⇒ 18p、シリアライザ 8p ⇒ 18p、ビュー 14p ⇒ 25p、URLconf 5p ⇒ 8p とそれぞれ大幅に増えています。特に、シリアライザは DRF の中でも大きな部分を占めるので、図を増やしてイチから分かりやすい解説を目指しました。

あとは、Django 初心者に少し優しくなりました。特に、前作ではモデルについての説明を「Django と同じ。以上！」としていたのを、きちんと章立てをして解説しています。内容は『現場で使える Django の教科書《基礎編》』からのほぼ抜粋になりますが、スッキリとまとめ直した上で DRF 向けに修正を加えています。

全体としては、加筆を120ページほどおこなっています。

そして、「そこまで言われても、前作の薄い本買っちゃったしなぁ。どうしよう・・」と悩んでいるあなたに朗報です。

前作『～の薄い本』を技術書典7に持ってきていただいた方、先着50名に、なんとワンコイン（500円）で新刊を買えるサービスを実施します！

ただし、お一人様1冊限りでお願いします（薄い本にはスタンプを押させていただきますのでご了承ください）。

頒布本情報

既刊の『現場で使える Django の教科書《基礎編》』『現場で使える Django の教科書《実践編》』を含めて、「Django の教科書」シリーズが３冊揃っています。

なおいつものように「会場特別価格」です。

実は今回の技術書典に合わせて《実践編》を１年振りにリニューアルして、Django 2.2 対応等をおこないました。

BOOTHで品切れ状態だった『現場で使えるDjangoの教科書《実践編》』ですが、ご希望にお応えして技術書典7で再販します。https://t.co/c2QczAIzhS

この一週間ずっと改訂作業をしていました。
・Django 2.2 対応
・4ページ増（180ページ）
その他諸々。思った以上に大変だった😇#技術書典#Djangopic.twitter.com/jzSB2WQdkT

— akiyoko/お74C@技術書典7「現場で使えるDRFの教科書」 (@aki_yok) September 14, 2019

これらの既刊については、Amazon や BOOTH で電子版とペーパー版が販売中です。

◆ 現場で使える Django の教科書《基礎編》 - Amazon（電子版・ペーパー版）

現場で使える Django の教科書《基礎編》

• 作者:横瀬明仁
• 発売日: 2018/08/21
• メディア: Kindle版
• この商品を含むブログを見る

◆ 現場で使える Django の教科書《基礎編》 - BOOTH（ペーパー版）
現場で使える Django の教科書《基礎編》【紙の本】 - あきよこブログ（akiyoko blog） - BOOTH

◆ 現場で使える Django の教科書《実践編》 - Amazon（電子版）

現場で使える Django の教科書《実践編》

• 作者:横瀬明仁
• 発売日: 2018/12/08
• メディア: Kindle版
• この商品を含むブログを見る

◆ 現場で使える Django の教科書《実践編》 - BOOTH（ペーパー版）
現場で使える Django の教科書《実践編》【紙の本】（技術書典6バージョン） - あきよこブログ（akiyoko - BOOTH

頒布場所

日時は 9/22（日）11時から17時まで、頒布場所は池袋サンシャインシティ3F 展示ホール「お74C」の「あきよこブログ」です。

見本誌を置いてますので、立ち読みだけでもお気軽にどうぞ。

最後に

余裕をもって始めたはずの執筆ですが、急遽、《実践編》の改訂と増版をしたのもあり、今回もギリギリの入稿になってしまいました。出すものは全部出した感があるので、自分なりにスッキリしています。技術書典当日は晴れやかに迎えられそうです！

runserver の実行（Run / Debug）設定

では、その設定方法です。*1

Django プロジェクトのひな型を作成する際に「startproject」コマンドを実行すると、管理コマンドを実行するための「manage.py」が自動生成されますよね。

その「manage.py」を右クリックし、「Create 'manage' ...」を選択します。なお、すでにこのプロジェクトで Run / Debug 設定をしたことがある場合は「manage.py」の右クリック時にこの選択肢が表示されないのでご注意ください（その場合は「Run」>「Edit Configurations...」メニューから Run / Debug の設定をおこなってください）。

Run / Debug 設定画面が表示されるので、「Parameters」に「runserver」と入力して、「OK」をクリックします。この際、「Name」には、分かりやすいようにたとえば「runserver」と入力しておけばよいでしょう。

Run / Debug 設定を済ませると、ナビゲーションバーの右側に「runserver」との表示がされます。

「runserver」の右側の虫アイコンをクリックすればデバッグ実行が開始されます。

デバッグ実行を開始すると、デバッグツールウィンドウ（Debug タブ）が起動してコンソールにログが出力されます。コードの途中にブレークポイントを置いておけば、コードが実行されたときにそこで中断されて変数などがデバッグができるようになります。

デバッグツールウィンドウの使い方については、公式ヘルプの「デバッグツールウィンドウ - ヘルプ | PyCharm」を参照してください。

いつもなら runserver を実行するのに

> python manage.py runserver

というコマンドをターミナルツールウィンドウ（Terminal タブ）を使って実行するところを、デバッグ実行はそれとは別のデバッグツールウィンドウ（Debug タブ）上で動作するため、ターミナルのウィンドウを専有することがありません。このため、makemigration、migrate、createsuperuser などの管理コマンドを実行するために、わざわざターミナル上で実行している runserver を停止して、その後 runserver を再実行する・・なんてことをする手間が不要になるのです。

これは便利ですよね〜 😚

おまけ ①

ここで、便利な裏技（？）をひとつ紹介します。

デバッグ実行中にブレークポイントでコードの実行を止めた状態ではデバッグツールウィンドウに「Debugger（デバッガ）」と「Console（コンソール）」という2つのタブが表示されます。ここで、「Console」タブをクリックして、Python ロゴのアイコン（Show Python Prompt）をクリックしてみてください。

すると、任意の Python コードが、止めたコード内で実行できるようになります。
ハイ、便利〜 😆

おまけ ②

runserver 実行時にオプションを指定したい場合がありますよね。

そんな場合は、ナビゲーションバー右側の「runserver」をクリックし、「Edit Configurations...」を選択して Run / Debug の設定画面を開きます（「Run」>「Edit Configurations...」メニューからでも開くことができます）。

「Parameters」に設定している「runserver」のところを「runserver --settings xxx」などと書き換えることで、実行時のオプションが指定可能です。

また、「Environment variables」から「DJANGO_SETTINGS_MODULE」などの環境変数を設定することも可能です。

おまけ ③

runserver の他によく利用する Django の管理コマンドとして、「test」（ユニットテストの実行）があります。

今回紹介した runserver の実行設定と同じようにワンクリックで Django プロジェクトのユニットテストを実行したい場合は、次のように「runserver」の設定をコピーするのが簡単です。

コピーしたら、「Parameters」を「test」に書き換えます（「Name」も適宜「test」などと書き換えます）。

あとは、「Run」アイコンか「Debug」アイコンをクリックするだけで Django プロジェクトのユニットテストが実行できるようになります。

おまけ ④

ここまでくると、Coverage.py を利用したカバレッジもワンクリックで実行したいですよね。

こんな感じで Run / Debug 設定をすれば OK です。

ポイントは、「Script path」のところを「Module name」に変更してから、「coverage」と手入力するところですかね（仮想環境下にインストールされた coverage の絶対パスを「Script path」に指定してもよいですが）。もちろん、pip で coverage をインストールしておいてくださいね。

ちなみに、有償版の PyCharm Professional では、PyCharm に内蔵された独自のカバレッジ機能を使ってワンクリックでカバレッジを取得することができます。*2

まとめ

PyCharm で Django の開発をするなら、runserver の実行（Run / Debug）設定をやっておきましょう。

1. 「manage.py」を右クリックして「Create 'manage' ...」を選択
2. Run / Debug 設定画面で「Parameters」に「runserver」と入力して「OK」

これだけです。ほんの5分足らず（もしかしたら1分くらいで？？）で設定は終わります。

runserver のデバッグ実行をポチッとワンクリック（ショートカットもあります）でスタートできる便利さを味わうと、もう PyCharm から離れられませんよ〜 😙

Enjoy Django & PyCharm !! 😉

明日は、nogisshさんの「Django Advent Calendar 2019 - Qiita」7日目の記事です。よろしくお願いします。

宣伝

Django の本を３冊書きました。Django 開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

Amazon（電子版／ペーパー版）

現場で使える Django の教科書《基礎編》

• 作者:横瀬 明仁
• 発売日: 2018/08/21
• メディア: Kindle版

BOOTH（ペーパー版）

現場で使える Django の教科書《実践編》

Amazon（電子版）

現場で使える Django の教科書《実践編》

• 作者:横瀬 明仁
• 発売日: 2018/12/08
• メディア: Kindle版

BOOTH（ペーパー版）

現場で使える Django REST Framework の教科書

Amazon（電子版）

現場で使える Django REST Framework の教科書 （Django の教科書シリーズ）

• 作者:横瀬 明仁
• 発売日: 2019/09/23
• メディア: Kindle版

BOOTH（ペーパー版）

2019年の akiyoko blog 振り返り

昨年一年間にアップした記事の本数は 6本で、昨年の 12本から半減しました。2018年に引き続いてずっと Django 本の執筆をしていたからですが、アウトプットの全体量が減ったというわけではありません。カンファレンスやオープンセミナーでの登壇や新人教育、同人誌の頒布など、むしろアウトプットは激増していると思います。

ちなみに、記事の更新頻度が減ったからか、ブログ全体のアクセス数も一昨年の 3/4 ほどに減ってしまっていました。

今年の目標

今年は、引き続き Django を盛り上げていくのはもちろんのこと、今執筆している商業誌をしっかりと書き上げることを大目標にしていきたいです。今年もすでにいろいろとイベントが予定されていて忙しそうなのですが、なんとか乗り切っていきたいと思います。

今年もよろしくお願い致します。

結論

Windows 10 ＋ Python 3.8 ＋ pip 19.2.2 以前という環境で、mysqlclient 1.4.6 の pip インストールが失敗する。その際、「Microsoft Visual C++ 14.0 is required」あるいは「include ファイルを開けません。'mysql.h':No such file or directory」といったエラーが出る。

対策としては、pip のバージョンを 19.2.3 以降にアップグレードするだけ。

なお、Microsoft Visual C++ をインストールする必要はありません。

詳細

(venv) C:\Users\akiyoko\work\mysqlclient-test>pip install --no-cache-dir mysqlclient
Collecting mysqlclient
  Downloading https://files.pythonhosted.org/packages/d0/97/7326248ac8d5049968bf4ec708a5d3d4806e412a42e74160d7f266a3e03a/mysqlclient-1.4.6.tar.gz (85kB)
     |████████████████████████████████| 92kB 990kB/s
Installing collected packages: mysqlclient
  Running setup.py install for mysqlclient ... error
    ERROR: Command errored out with exit status 1:
     command: 'c:\users\akiyoko\work\mysqlclient-test\venv\scripts\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\akiyoko\\AppData\\Local\\Temp\\pip-install-yluhih0a\\mysqlclient\\setup.py'"'"'; __file__='"'"'C:\\Users\\akiyoko\\AppData\\Local\\Temp\\pip-install-yluhih0a\\mysqlclient\\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\akiyoko\AppData\Local\Temp\pip-record-4l7b4jv9\install-record.txt' --single-version-externally-managed --compile --install-headers 'c:\users\akiyoko\work\mysqlclient-test\venv\include\site\python3.8\mysqlclient'
         cwd: C:\Users\akiyoko\AppData\Local\Temp\pip-install-yluhih0a\mysqlclient\
    Complete output (24 lines):
    running install
    running build
    running build_py
    creating build
    creating build\lib.win-amd64-3.8
    creating build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\__init__.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\_exceptions.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\compat.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\connections.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\converters.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\cursors.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\release.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\times.py -> build\lib.win-amd64-3.8\MySQLdb
    creating build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\__init__.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\CLIENT.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\CR.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\ER.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\FIELD_TYPE.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\FLAG.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    running build_ext
    building 'MySQLdb._mysql' extension
    error: Microsoft Visual C++ 14.0 is required. Get it with "Microsoft Visual C++ Build Tools": https://visualstudio.microsoft.com/downloads/
    ----------------------------------------
ERROR: Command errored out with exit status 1: 
    ...（略）...

(venv) C:\Users\akiyoko\work\mysqlclient-test>pip install --no-cache-dir mysqlclient
Collecting mysqlclient
  Downloading https://files.pythonhosted.org/packages/d0/97/7326248ac8d5049968bf4ec708a5d3d4806e412a42e74160d7f266a3e03a/mysqlclient-1.4.6.tar.gz (85kB)
     |████████████████████████████████| 92kB 845kB/s
Installing collected packages: mysqlclient
  Running setup.py install for mysqlclient ... error
    ERROR: Command errored out with exit status 1:
     command: 'c:\users\akiyoko\work\mysqlclient-test\venv\scripts\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\akiyoko\\AppData\\Local\\Temp\\pip-install-kp34ucod\\mysqlclient\\setup.py'"'"'; __file__='"'"'C:\\Users\\akiyoko\\AppData\\Local\\Temp\\pip-install-kp34ucod\\mysqlclient\\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\akiyoko\AppData\Local\Temp\pip-record-3csqetin\install-record.txt' --single-version-externally-managed --compile --install-headers 'c:\users\akiyoko\work\mysqlclient-test\venv\include\site\python3.8\mysqlclient'
         cwd: C:\Users\akiyoko\AppData\Local\Temp\pip-install-kp34ucod\mysqlclient\
    Complete output (30 lines):
    running install
    running build
    running build_py
    creating build
    creating build\lib.win-amd64-3.8
    creating build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\__init__.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\_exceptions.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\compat.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\connections.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\converters.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\cursors.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\release.py -> build\lib.win-amd64-3.8\MySQLdb
    copying MySQLdb\times.py -> build\lib.win-amd64-3.8\MySQLdb
    creating build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\__init__.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\CLIENT.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\CR.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\ER.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\FIELD_TYPE.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    copying MySQLdb\constants\FLAG.py -> build\lib.win-amd64-3.8\MySQLdb\constants
    running build_ext
    building 'MySQLdb._mysql' extension
    creating build\temp.win-amd64-3.8
    creating build\temp.win-amd64-3.8\Release
    creating build\temp.win-amd64-3.8\Release\MySQLdb
    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -Dversion_info=(1,4,6,'final',0) -D__version__=1.4.6 "-IC:\Program Files (x86)\MySQL\MySQL Connector C 6.1\include\mariadb" -Ic:\users\akiyoko\work\mysqlclient-test\venv\include -IC:\Users\akiyoko\AppData\Local\Programs\Python\Python38\include -IC:\Users\akiyoko\AppData\Local\Programs\Python\Python38\include "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\include" /TcMySQLdb/_mysql.c /Fobuild\temp.win-amd64-3.8\Release\MySQLdb/_mysql.obj /Zl /D_CRT_SECURE_NO_WARNINGS
    _mysql.c
    MySQLdb/_mysql.c(29): fatal error C1083: include ファイルを開けません。'mysql.h':No such file or directory
    error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.25.28610\\bin\\HostX86\\x64\\cl.exe' failed with exit status 2
    ----------------------------------------
ERROR: Command errored out with exit status 1:
    ...（略）...

原因

>>> from pip._internal.pep425tags import get_supported
>>> get_supported()

PyCharm CE のインストール手順

まずは PyCharm CE 2020.1 のインストール手順について軽く説明します。

PyCharm 公式ダウンロードページから、「コミュニティ」（PyCharm CE）の方の「ダウンロード」ボタンをクリックして、インストーラをダウンロードします。

あとはインストーラをダブルクリックして、表示される内容に従ってインストールを実行してください。

デフォルトでは、Windows の場合は

• C:\Program Files\JetBrains\PyCharm Community Edition 2020.1

macOS の場合は

• ~/Library/Application Support/JetBrains/PyCharmCE2020.1

にインストールされます。

環境設定

上部メニューの［File］ >［Settings］（macOS 版では［PyCharm］ >［Preferences］）から、PyCharm の環境設定が変更できます。

VMオプション設定

［Help］ >［Edit Custom VM Options...］

を選択すると、VMオプションの設定をカスタマイズするためのファイルを編集することができます。 *3

-Xms128m
-Xmx750m
-XX:ReservedCodeCacheSize=240m
...（略）...

-Xms128m
-Xmx2048m
-XX:ReservedCodeCacheSize=240m
...（略）...

プロジェクトツールウィンドウ設定

プロジェクトビューの歯車アイコンをクリックして、ツールウィンドウの設定をおこないます。
　

日本語化

「Pleiades 日本語化プラグイン」を利用すれば、PyCharm の UI を日本語化することも可能です。ただし JetBrains 公式のものではないため、動作は保証されていないのでご注意ください。

pleiades.io

13．Pleiades 日本語化プラグインの導入手順

まず、「Pleiades 日本語化プラグイン」のダウンロードサイトから zip ファイルをダウンロードします（OS に合わせてダウンロードしてください）。

なお、PyCharm バージョン 2020.1 に対応した最新の Pleiades 日本語化プラグインを使用しないと動作しないのでご注意ください。 *4

zipファイルを解凍し、setup.exe（macOS の場合は setup.app）をダブルクリックしてインストーラを起動します。

「日本語化するアプリケーション」の「選択」ボタンをクリックして、Windows の場合は

• C:\Program Files\JetBrains\PyCharm Community Edition 2020.1\bin\pycharm64.exe

macOS の場合は

• /Applications/PyCharm CE.app

を選択して、「日本語化する」ボタンをクリックします。

あとは、PyCharm を再起動すれば OK です。

　

便利なショートカット集

最後に非常に便利なショートカットをいくつか紹介します。

JetBrains 公式の PyCharm チートシート

• Windows 版 PyCharm チートシート
• macOS 版 PyCharm チートシート

もありますが、さすがに全部覚えきれませんよね。そこで、私が特に重要と考えるショートカットを抜粋してみました。黄色で強調したショートカットだけでも覚えておくと、効率が劇的に上がりますのでぜひ活用してください。

まとめ

個人的に、PyCharm は Python の統合開発環境（IDE）として最強だと考えています。デフォルトの環境設定を何もイジらなくても快適に動いてくれるというのも大きな魅力のひとつが、今回のような環境設定をすると PyCharm はさらに使いやすくなります。

それでは、素敵な PyCharm ライフを！

TL;DR

フィールドの auto_now_add, auto_now オプションについて

登録時
・auto_now_add=True
・auto_now=True
更新時
・auto_now=True
のフィールドに現在日時が自動でセットされる。

ただし、任意の値をセットできない。https://t.co/jqOYzylLxj

freezegun を使うと簡単にテストできる。#Djangoメモ

— akiyoko/ 『現場で使えるDjangoの教科書』 (@aki_yok) May 21, 2020

挙動

たとえば、

shop/models.py

from django.db import models


classBook(models.Model):
    """本モデル"""classMeta:
        db_table = 'book'
        verbose_name = verbose_name_plural = '本'

    title = models.CharField('タイトル', max_length=255)
    price = models.PositiveIntegerField('価格', null=True, blank=True)
    created_at = models.DateTimeField('登録日時', auto_now_add=True)
    updated_at = models.DateTimeField('更新日時', auto_now=True)

    def__str__(self):
        return self.title

というフィールドがあるとすると、

登録時

• 「auto_now_add=True」のフィールド（created_at）に現在日時が自動的にセットされる
• 「auto_now=True」のフィールド（updated_at）に現在日時が自動的にセットされる

更新時

• 「auto_now=True」のフィールド（updated_at）に現在日時が自動的にセットされる

という挙動になります。

つまり、テストを書くとこういうことになります（参考までに freezegunと unittest.mockを使ったものを併記）。

shop/tests/test_models.py

from datetime import datetime
from unittest.mock import patch

from django.test import TestCase
from django.utils import timezone
from freezegun import freeze_time

from ..models import Book


classTestBook(TestCase):

    @freeze_time('2020-01-01 01:01:01')
    deftest_save_with_freezegun(self):
        book = Book(title='Django本', price=1500)
        # 登録
        book.save()

        # 登録日時・更新日時のどちらも値がセットされる
        self.assertEqual(book.created_at, datetime(2020, 1, 1, 1, 1, 1, tzinfo=timezone.utc))
        self.assertEqual(book.updated_at, datetime(2020, 1, 1, 1, 1, 1, tzinfo=timezone.utc))

        with(freeze_time('2020-02-02 02:02:02')):
            # 更新
            book.save()

        # 更新日時のみが更新される
        self.assertEqual(book.created_at, datetime(2020, 1, 1, 1, 1, 1, tzinfo=timezone.utc))
        self.assertEqual(book.updated_at, datetime(2020, 2, 2, 2, 2, 2, tzinfo=timezone.utc))

    @patch('django.utils.timezone.now',
           return_value=datetime(2020, 1, 1, 1, 1, 1, tzinfo=timezone.utc))
    deftest_save_with_mock(self, _mock_now):
        book = Book(title='Django本', price=1500)
        # 登録
        book.save()

        # 登録日時・更新日時のどちらも値がセットされる
        self.assertEqual(book.created_at, datetime(2020, 1, 1, 1, 1, 1, tzinfo=timezone.utc))
        self.assertEqual(book.updated_at, datetime(2020, 1, 1, 1, 1, 1, tzinfo=timezone.utc))

        _mock_now.return_value = datetime(2020, 2, 2, 2, 2, 2, tzinfo=timezone.utc)
        # 更新
        book.save()

        # 更新日時のみが更新される
        self.assertEqual(book.created_at, datetime(2020, 1, 1, 1, 1, 1, tzinfo=timezone.utc))
        self.assertEqual(book.updated_at, datetime(2020, 2, 2, 2, 2, 2, tzinfo=timezone.utc))

　
フィールドに現在日時が自動的にセットされる仕組みを見てみると、次のように、pre_save() で django.utils.timezone.now() が呼ばれています。

django.db.models.fields.DateTimeField.pre_save　*1

defpre_save(self, model_instance, add):
        if self.auto_now or (self.auto_now_add and add):
            value = timezone.now()
            setattr(model_instance, self.attname, value)
            return value
        else:
            returnsuper().pre_save(model_instance, add)

そして django.utils.timezone.now() では、Django の設定ファイルの「USE_TZ」が True の場合は datetime.datetime.utcnow() が呼ばれています。

django.utils.timezone.now　*2

defnow():
    """    Return an aware or naive datetime.datetime, depending on settings.USE_TZ."""if settings.USE_TZ:
        # timeit shows that datetime.now(tz=utc) is 24% slowerreturn datetime.utcnow().replace(tzinfo=utc)
    else:
        return datetime.now()

freezegun の freezegun.api.FakeDatetime が次のように datetime.datetime.now() や utcnow() などをモックしてくれているので、「auto_now_add」や「auto_now」にも適用できるのですね。よかった。

freezegun.api.FakeDatetime　*3

classFakeDatetime(with_metaclass(FakeDatetimeMeta, real_datetime, FakeDate)):

    ...（略）...

    @classmethoddefnow(cls, tz=None):
        now = cls._time_to_freeze() or real_datetime.now()
        if tz:
            result = tz.fromutc(now.replace(tzinfo=tz)) + cls._tz_offset()
        else:
            result = now + cls._tz_offset()
        return datetime_to_fakedatetime(result)

    ...（略）...

    @classmethoddefutcnow(cls):
        result = cls._time_to_freeze() or real_datetime.utcnow()
        return datetime_to_fakedatetime(result)

    ...（略）...

「auto_now_add」や「auto_now」を使うことによる弊害

便利でよいのですが、二点ほど弊害があります。

>>> from shop.models import Book
>>> from datetime import datetime
>>> from django.utils import timezone
>>> book = Book()
>>> book.updated_at = datetime(2020, 1, 1, 1, 1, 1, tzinfo=timezone.utc)
>>> book.save()
>>> book.updated_at
datetime.datetime(2020, 5, 21, 6, 41, 7, 219328, tzinfo=<UTC>)

classDateField(DateTimeCheckMixin, Field):
    ...（略）...

    def__init__(self, verbose_name=None, name=None, auto_now=False,
                 auto_now_add=False, **kwargs):
        self.auto_now, self.auto_now_add = auto_now, auto_now_add
        if auto_now or auto_now_add:
            kwargs['editable'] = False
            kwargs['blank'] = Truesuper().__init__(verbose_name, name, **kwargs)

    ...（略）...

classDateTimeField(DateField):
    ...（略）...

    # __init__ is inherited from DateField

from django.contrib import admin

from .models import Book


classBookAdmin(admin.ModelAdmin):
    fields = ('title', 'price', 'created_at', 'updated_at')
    readonly_fields = ('created_at', 'updated_at')


admin.site.register(Book, BookAdmin)

宣伝

Django の本を３冊書きました。Django 開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

★ Amazon（電子版／ペーパー版）

現場で使える Django の教科書《基礎編》

横瀬 明仁 ／ NextPublishing Authors Press (2018/8/26)

Amazon

Kindle

★ BOOTH（ペーパー版）

現場で使える Django の教科書《実践編》

★ Amazon（電子版）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django REST Framework の教科書

★ Amazon（電子版）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

どんな本なの？

皆さんは、管理サイト（Django Admin）を使っていますか？

おそらく Django を利用している開発者の ほとんどが「イエス」と答えるでしょう。実際、事前アンケートでは Django 利用者の９割近くが「いつも使っている」あるいは「たまに使っている」と回答しています。

しかしながら、その仕組みをきちんと理解せずに使っている人が意外と多いのではないでしょうか。管理サイトは Django の仕組みや設計思想をうまく活かしたアプリになっており、管理サイトを理解することはそれらを知る手助けにもなります。これからも Django を長く使っていくのであれば、管理サイトを深く知っておくことは必ず強力な武器になるでしょう。

また、管理サイトはあらゆるモデルに対応できるように汎用的に作られており、ある程度のカスタマイズも考慮されていて幅広いユースケースで利用することができます。実際の現場では「開発中のテストデータ投入」や「システム利用ユーザーの情報管理」で利用しているケースが多いようです。

管理サイトには利用するメリットがたくさんありますが、これについても事前にアンケートを採ってみました。

結果を見ると、デフォルトで使える点やほんの数行書くだけでモデルの CRUD 機能が追加できる点が特に高く評価されていて、お手軽で簡単に使えるというのが管理サイトの大きなメリットになっています。

しかし、当然ながら管理サイトは「万能」ではありません。たとえば「少しカスタマイズすれば一般ユーザー向けの画面として使えそう」と目論んでいたら、後になって管理サイトの特性や限界を無視した要望がいっぱい出てきて余計に工数が膨らんでしまったというのはありがちな失敗パターンです。

メリットばかりがクローズアップされがちな管理サイトですが、ここで敢えて負の面に目を向けてみます。次のアンケート結果を見てください。

「ある程度以上のカスタマイズになると難易度が上がる」や「簡単にカスタマイズできるかどうかのジャッジにノウハウや調査が必要」など、カスタマイズ系のデメリットが圧倒的に多いことが分かります。「日本語の情報が少ない」や「仕様を把握するのにひと苦労」が多いのは、困ったときのヒントが得られにくいという状況を表しているものと考えられます。これらを踏まえると、管理サイトをカスタマイズする場合は 事前にその限界（基本仕様でどこまでできるのか）とカスタマイズの特性（どんなカスタマイズが簡単でどんなカスタマイズが難しいのか）を十分に把握しておく必要があるでしょう。

そこで本書では、いつも使う管理サイトだからこそ知っておきたい現場レベルの知識やノウハウについて、次の3つのポイントを中心に解説していきます。

1. 管理サイトの基本仕様
2. 管理サイトの仕組みを活かしたカスタマイズ戦略
3. カスタマイズ後のテスト

本書を読めば、管理サイトの基本から応用に至るまでの幅広い知識が得られ、Django への理解がさらに深まるでしょう。

対象読者

本書の読者としては、

• 管理サイト（Django Admin）のことをもっと知りたい方
• これから管理サイトのカスタマイズをしようとしている方

を想定しています。

特に、これから管理サイトのカスタマイズをしようとしている方には是非とも読んでほしい内容になっています。

もし管理サイトに興味がなくても、

• ユーザーモデルやパーミッションの仕組み
• テンプレートや静的ファイルのルックアップの仕組み
• Selenium を使ったブラウザテストの書き方

などに興味があれば刺さるかもしれません。

最低限必要な知識としては「Django の仕組みが何となく理解できていること」です。Django 公式チュートリアルや Django Girls チュートリアルをひと通り終えたくらいであれば問題はないでしょう。また、拙著『現場で使える Django の教科書《基礎編》』を読み終えたくらいの知識があれば万全です。

以降で、章ごとの読みどころを紹介していきます。

第１章： 管理サイトの基本仕様

管理サイトは意外と機能が豊富で、その仕様を把握するのにもひと苦労です。そこで本書では手始めに、管理サイトの基本仕様を詳しく紹介しています。

まず、管理サイトの全体像が捉えやすいように画面遷移図（紙面サンプル ① を参照）を示しています。こういった画面遷移図ってググっても何故かなかなか見つからないんですよね。。

その後、Django 初心者向けに利用手順を紹介したあとで、管理サイトが利用している Django の仕組みである「ユーザーモデル」「パーミッションによるアクセス制御」「変更履歴」について解説しています。パーミッションあたりはあまり理解していない人も多いのではないでしょうか。

最後に、画面ごとに詳細な説明をしています。管理サイトは普段は気付かないような隠れ機能があったりするので、手の込んだ仕掛けに驚かされるでしょう。

第２章： 管理サイトのカスタマイズ

この章で気を付けたのは、なるべく図を多くするということです。公式ドキュメントや特に Stack Overflow などで検索した場合は図が無かったりするので、「一体どんなカスタマイズができるのかイメージが掴めない」ということが多いのです。そういう不満を払しょくするために、このカスタマイズをするとどんなことが実現できるのかがビジュアルで掴めるようにしてみました。

そしてこの章の目玉は、カスタマイズに利用できる AdminSite と ModelAdmin のクラス変数とメソッドの一覧表（紙面サンプル ④ を参照）と、管理サイトで使われるテンプレートファイルの一覧表です。こういうのがあると便利だなという気持ちと書くのがめちゃくちゃ大変だなという気持ちで随分葛藤しましたが、今となっては書いて正解だったと感じています。

第３章： 管理サイトのテスト

管理サイトのカスタマイズをする場合は AdminSite や ModelAdmin のクラス変数、メソッドをオーバーライドすることになりますが、それらの断片化したコードだけをユニットテストして例えカバレッジを100％にしたところで、機能が想定通りに動作することを保証したことにはなりません。そんなわけで、管理サイトのテストでは画面ごとにビューのテストをした上で、「lxml」などのパッケージを利用してレンダリングされた HTML から要素をパースして検証するなどの工夫が必要になります。第３章の前半では、そういったテストケースのコード例を挙げて解説しています。

章の後半では、Selenium を使ったブラウザテストについて解説しています。Selenium を使ったテストでは通常、テンプレートの HTML 要素自体や class 属性に変更が加わるとテスト側にも修正を加えねばならず保守が大変になりますが、管理サイトはテンプレートが固まっているためブラウザテストとの相性がよいです。特に、管理サイトでは、Selenium によるブラウザテストをするための AdminSeleniumTestCase が提供されています。章の最後に、このクラスを継承したテストコード例を紹介しています。

頒布本情報

これから入稿するので価格はまだ決めていませんが、技術書典９向けの特別価格として「送料込み 1,200円」くらいを予定しています。

価格については決まり次第、更新します。

最後に

今回、いわゆる「管理サイト本」を書いた理由としては、自分の知識の整理のためということもありますが、どちらかというと Django をもっと現場に普及させたいという気持ちの方が強いです。つまり、現場で頻繁に使う管理サイトのまとまった日本語情報があれば、Django がもっと現場で使われやすくなるんじゃないかと思ったのです。

きっかけは、現場で管理サイトのカスタマイズ案件が二つ続いたことでした。そこには主にレビューで参加したのですが、「担当者が違うとこんなにも書き方が違うのか。保守が大変そうだなぁ」「わざわざこんなことしなくてもフックポイントがあるのに」「あらら、全部 Selenium テストで書いちゃったのね」などとガク然としたのです。そのときに「これを見といてね」と言えるものがなかった苦い経験から、管理サイトを少し真面目に使おうとするときに現場に一冊あれば安心な本を書こうと思い至ったのでした。

ということで、Django 開発のお供に『現場で使える Django 管理サイトのつくり方』を是非どうぞ！！😊

宣伝

これまで Django の本を３冊出しました。Django 開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第1弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文180ページ。

★ Amazon（電子版／ペーパー版）

現場で使える Django の教科書《基礎編》

横瀬 明仁 ／ NextPublishing Authors Press (2018/8/26)

Amazon

Kindle

★ BOOTH（ペーパー版）

現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第2弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。

★ Amazon（電子版）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」（通称「DRF」）にフォーカスした、「現場で使える Django の教科書」シリーズの第3弾。B5・本文204ページ。

★ Amazon（電子版）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

はじめに

トランザクションは連続した複数のデータベース操作をひとつにまとめたものです。

トランザクションは、データベースをある一貫した状態から別の一貫した状態へ変更するアクションを1つに束ねたものである。トランザクション処理は、既知の一貫した状態のデータベースを維持するよう設計されており、相互依存のある複数の操作が全て完了するか、全てキャンセルされることを保証する。

トランザクション処理 - Wikipedia

一連の処理がすべて完了したらレコードの登録・変更・削除をまとめてデータベースに反映（コミット）し、エラーなどで一連の処理が完了しなかった場合はその過程でおこなわれたレコードの登録・変更・削除を無かったことにする（ロールバック）必要がある場合にトランザクションが利用されます。

デフォルトはオートコミット

Django のデフォルトでは、データベースのレコードを登録・更新・削除するための各クエリは、モデルオブジェクトの save() や delete() が実行された時点で即座にデータベースに反映されます。これは「オートコミットモード」と呼ばれます。*1

つまり、デフォルトではトランザクションは利用されません。

例えば、本の購入決済をするためのビューの中で、次のように連続したレコード操作があるとします。

デフォルトでは、「① 注文情報を登録」「③ 在庫数を 1 減らす」「④ 注文情報のステータスを更新」といったクエリはそれぞれの時点でコミット（データベースに反映）されます。

PostgreSQL の SQL ログは次のように出力されます。

《 PostgreSQL の SQL ログ 》

[pid-1] SET TIME ZONE 'UTC'
[pid-1] SELECT "book"."id", "book"."title", "book"."price" FROM "book" WHERE "book"."id" = 1 LIMIT 21
[pid-1] INSERT INTO "order" ("status", "total_amount", "ordered_by_id", "ordered_at") VALUES ('01', 1000, 1, '2020-12-01T03:00:18.900883+00:00'::timestamptz) RETURNING "order"."id"
[pid-1] SELECT "stock"."id", "stock"."book_id", "stock"."quantity", "stock"."updated_at" FROM "stock" WHERE "stock"."book_id" = 1 LIMIT 21
[pid-1] UPDATE "stock" SET "book_id" = 1, "quantity" = 0, "updated_at" = '2020-12-01T03:00:18.927935+00:00'::timestamptz WHERE "stock"."id" = 1
[pid-1] UPDATE "order" SET "status" = '02', "total_amount" = 1000, "ordered_by_id" = 1, "ordered_at" = '2020-12-01T03:00:18.900883+00:00'::timestamptz WHERE "order"."id" = 1

この中の INSERT や UPDATE は逐一コミットされます。

モデル、およびビューのソースコードのイメージは次の通りです。

shop/models.py（モデル）

from django.contrib.auth import get_user_model
from django.db import models

User = get_user_model()


classBook(models.Model):
    """本モデル"""classMeta:
        db_table = 'book'
        verbose_name = verbose_name_plural = '本'

    title = models.CharField('タイトル', max_length=255, unique=True)
    price = models.PositiveIntegerField('価格', null=True, blank=True)

    def__str__(self):
        return self.title


classBookStock(models.Model):
    """在庫モデル"""classMeta:
        db_table = 'stock'
        verbose_name = verbose_name_plural = '在庫'

    book = models.OneToOneField(Book, verbose_name='本', on_delete=models.CASCADE)
    quantity = models.PositiveIntegerField('在庫数', default=0)
    updated_at = models.DateTimeField('更新日時', auto_now=True)

    def__str__(self):
        return f'{self.book.title} ({self.quantity})'classOrder(models.Model):
    """注文モデル"""classMeta:
        db_table = 'order'
        verbose_name = verbose_name_plural = '注文'

    STATUS_PAYMENT_PROCESSING = '01'
    STATUS_PAYMENT_OK = '02'
    STATUS_PAYMENT_NG = '03'
    STATUS_PAYMENT_ERROR = '09'
    STATUS_CHOICES = (
        (STATUS_PAYMENT_PROCESSING, '決済中'),
        (STATUS_PAYMENT_OK, '決済OK'),
        (STATUS_PAYMENT_NG, '決済NG'),
        (STATUS_PAYMENT_ERROR, '決済エラー'),
    )

    status = models.CharField('ステータス', max_length=2, choices=STATUS_CHOICES)
    total_amount = models.PositiveIntegerField('金額合計')
    ordered_by = models.ForeignKey(User, verbose_name='注文者', on_delete=models.PROTECT, editable=False)
    ordered_at = models.DateTimeField('注文日時', auto_now_add=True)

    def__str__(self):
        return f'{self.get_status_display()} ({self.ordered_at:%Y-%m-%d %H:%M})'

shop/views.py（ビュー）

from django.http.response import HttpResponseRedirect
from django.shortcuts import get_object_or_404, reverse
from django.views import View

from .models import Book, BookStock, Order


classCheckoutView(View):
    ...（略）...

    defpost(self, request, *args, **kwargs):
        book = get_object_or_404(Book, pk=kwargs['pk'])

        # ① 注文情報を登録
        order = Order(
            status=Order.STATUS_PAYMENT_PROCESSING,
            total_amount=book.price,
            ordered_by=request.user,
        )
        order.save()

        # ② 在庫数を確認
        book_stock = get_object_or_404(BookStock, book=book)
        # ③ 在庫数を1減らして更新
        book_stock.quantity -= 1
        book_stock.save()

        ...（決済処理）...

        # ④ 注文情報のステータスを更新
        order.status = Order.STATUS_PAYMENT_OK
        order.save()

        ...（略）...

        return HttpResponseRedirect(reverse('shop:checkout_complete'))

PostgreSQL へのデータベース接続設定は次のようになります。

config/settings.py（設定ファイル）

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mysite',
        'USER': 'mysiteuser',
        'PASSWORD': 'mysiteuserpass',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

ここまでは OK ですよね。

次に、ビューの中で予期せぬエラーが発生した場合について考えてみましょう。

デフォルトのオートコミットモードでは、エラーが発生する前の処理はすでにコミットされてしまっているので、プログラムで明示的に後始末処理（いわゆる手動ロールバック）をしないといけません。いろんなところで予期せぬエラーが発生することを考えると、いちいち手動でロールバック処理を書くのは大変ですよね。そこで Django ORM が提供している「トランザクション」 *2の機能を利用します。

このように一連の処理をトランザクションで囲んでおけば、エラーが発生した場合のロールバック処理を自動でおこなってくれるのです。

Django でトランザクションを利用するには、大きく次の二つの方法があります。

• 【方法１】ATOMIC_REQUESTS を有効化する
• 【方法２】transaction.atomic() で囲む

それぞれについて詳しく見ていきましょう。

【方法１】ATOMIC_REQUESTS を有効化する

トランザクションを適用するには、データベースの「ATOMIC_REQUESTS」設定を有効化するのが一番手っ取り早いです。有効化するには、次のように設定ファイルの「DATABASES」の「ATOMIC_REQUESTS」を True（デフォルトは False）にします。*3

config/settings.py（設定ファイル）

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mysite',
        'USER': 'mysiteuser',
        'PASSWORD': 'mysiteuserpass',
        'HOST': 'localhost',
        'PORT': '5432',
        'ATOMIC_REQUESTS': True,  # 追加
    }
}

モデルやビューには何も手を加える必要はないので簡単ですよね。これだけで、ビュー全体のデータベース操作がひとつのトランザクションで囲まれます。

なお、ミドルウェア内のデータベース操作はこのトランザクションの範囲外となるので要注意です（あくまでビューの開始から終了までが一つのトランザクションになります）。

SQLクエリログは次のように出力されます。

《 PostgreSQL の SQL ログ 》

[pid-1] SET TIME ZONE 'UTC'
[pid-1] BEGIN
[pid-1] SELECT "book"."id", "book"."title", "book"."price" FROM "book" WHERE "book"."id" = 1 LIMIT 21
[pid-1] INSERT INTO "order" ("status", "total_amount", "ordered_by_id", "ordered_at") VALUES ('01', 1000, 1, '2020-12-01T03:01:53.319483+00:00'::timestamptz) RETURNING "order"."id"
[pid-1] SELECT "stock"."id", "stock"."book_id", "stock"."quantity", "stock"."updated_at" FROM "stock" WHERE "stock"."book_id" = 1 LIMIT 21
[pid-1] UPDATE "stock" SET "book_id" = 1, "quantity" = 0, "updated_at" = '2020-12-01T03:01:53.334689+00:00'::timestamptz WHERE "stock"."id" = 1
[pid-1] UPDATE "order" SET "status" = '02', "total_amount" = 1000, "ordered_by_id" = 1, "ordered_at" = '2020-12-01T03:01:53.319483+00:00'::timestamptz WHERE "order"."id" = 2
[pid-1] COMMIT

すべての SQL が「BEGIN」と「COMMIT」で囲まれていて、これがひとつのトランザクションになっています。

予期せぬエラーなどで ビューから例外が漏れた場合、Django ORM によるロールバックが自動でおこなわれます。その際の SQL ログは次のようになります。ちなみに、検査制約「CONSTRAINT stock_quantity_check CHECK (quantity >= 0)」が付いた在庫テーブルの在庫数（quantity）が「0」の場合に在庫を減らそうとしてエラーが出ちゃった例です。

《 PostgreSQL の SQL ログ 》

[pid-1] SET TIME ZONE 'UTC'
[pid-1] BEGIN
[pid-1] SELECT "book"."id", "book"."title", "book"."price" FROM "book" WHERE "book"."id" = 1 LIMIT 21
[pid-1] INSERT INTO "order" ("status", "total_amount", "ordered_by_id", "ordered_at") VALUES ('01', 1000, 1, '2020-12-01T03:02:29.849050+00:00'::timestamptz) RETURNING "order"."id"
[pid-1] SELECT "stock"."id", "stock"."book_id", "stock"."quantity", "stock"."updated_at" FROM "stock" WHERE "stock"."book_id" = 1 LIMIT 21
[pid-1] UPDATE "stock" SET "book_id" = 1, "quantity" =  -1, "updated_at" = '2020-12-01T03:02:29.856001+00:00'::timestamptz WHERE "stock"."id" = 1
[pid-1] ERROR:  new row for relation "stock" violates check constraint "stock_quantity_check"
[pid-1] ROLLBACK

ERROR の後に、ROLLBACK がおこなわれています。

「ATOMIC_REQUESTS」の利点は導入の手軽さですが、お手軽な反面、公式ドキュメントにもあるように、同時アクセス数が多いようなシステムではスループットを下げてしまう可能性もあり、性能面での注意が必要です。

このトランザクションモデルは簡潔ではありますが、トラフィックが増加するときには非効率となります。全てのビューでトランザクションを扱うとオーバーヘッドが増加します。パフォーマンスへの影響は、アプリケーションのクエリパターンと、どれだけうまくデータベースがロッキングを扱うかに依存します。

データベースのトランザクション | Django ドキュメント | Django

【方法２】transaction.atomic() で囲む

「ATOMIC_REQUESTS」の代わりに、transaction.atomic()を使ってトランザクションを実現する方法もあります。「ATOMIC_REQUESTS」がビュー全体をトランザクションで囲むのに対し、transaction.atomic() は with 句を使ってトランザクションの適用範囲を自由に設定することができます。

先の購入決済のビューの例では、在庫数の更新は可能な限り迅速にデータベースに反映しておく必要があるでしょう。例えば、在庫があと「1」しか残っていない状態で、あるユーザが決済処理を実行中だと、在庫は実質「0」ですよね。このタイミングで他のユーザが在庫テーブルを参照した場合に在庫数が「1」のままにならないように、在庫数を減らす更新を決済処理の前に一旦コミットして在庫を引き当て（取り置き）しておくようにしてみます。

transaction.atomic() を適用したコード例は次のようになります。設定ファイルの「ATOMIC_REQUESTS」の設定は無効化しておきます。

shop/views.py（ビュー）

from django.db import transaction  # 追加from django.http.response import HttpResponseRedirect
from django.shortcuts import get_object_or_404, reverse
from django.views import View

from .models import Book, BookStock, Order


classCheckoutView(View):
    ...（略）...

    defpost(self, request, *args, **kwargs):
        book = get_object_or_404(Book, pk=kwargs['pk'])

        with transaction.atomic():  # 追加# ① 注文情報を登録
            order = Order(
                status=Order.STATUS_PAYMENT_PROCESSING,
                total_amount=book.price,
                ordered_by=request.user,
            )
            order.save()

            # ② 在庫数を確認
            book_stock = get_object_or_404(BookStock, book=book)
            # ③ 在庫数を1減らして更新
            book_stock.quantity -= 1
            book_stock.save()

        ...（決済処理）...

        with transaction.atomic():  # 追加# ④ 注文情報のステータスを更新
            order.status = Order.STATUS_PAYMENT_OK
            order.save()

        ...（略）...

        return HttpResponseRedirect(reverse('shop:checkout_complete'))

これで、次のようにトランザクションを細かく分けることができるようになりました。*4

《 PostgreSQL の SQL ログ 》

[pid-1] SET TIME ZONE 'UTC'
[pid-1] SELECT "book"."id", "book"."title", "book"."price" FROM "book" WHERE "book"."id" = 1 LIMIT 21
[pid-1] BEGIN
[pid-1] INSERT INTO "order" ("status", "total_amount", "ordered_by_id", "ordered_at") VALUES ('01', 1000, 1, '2020-12-01T03:03:11.428997+00:00'::timestamptz) RETURNING "order"."id"
[pid-1] SELECT "stock"."id", "stock"."book_id", "stock"."quantity", "stock"."updated_at" FROM "stock" WHERE "stock"."book_id" = 1 LIMIT 21
[pid-1] UPDATE "stock" SET "book_id" = 1, "quantity" = 0, "updated_at" = '2020-12-01T03:03:11.442959+00:00'::timestamptz WHERE "stock"."id" = 1
[pid-1] COMMIT
[pid-1] BEGIN
[pid-1] UPDATE "order" SET "status" = '02', "total_amount" = 1000, "ordered_by_id" = 1, "ordered_at" = '2020-12-01T03:03:11.428997+00:00'::timestamptz WHERE "order"."id" = 3
[pid-1] COMMIT

「BEGIN」と「COMMIT」で囲まれたトランザクションを2つ確認することができました。

（おまけ）ATOMIC_REQUESTS を有効化しているときに、特定のビュー内で自前でトランザクションを切る方法

ほとんどのビューではビュー全体をひとつのトランザクションで囲めばよいが、一部のビューでのみトランザクションを細かく切らないといけないといったケースがあります。そのような場合には、ATOMIC_REQUESTS を有効にした上で、対象のビューに「django.db.transaction.non_atomic_requests」を適用して ATOMIC_REQUESTS の効果を無効化してしまえばよいです。注意点としては、Django のクラスベースビューにこれを適用するには、method_decoratorを使って dispatch() メソッドに non_atomic_requestsを適用してあげる必要があります。

参考
- データベースのトランザクション | Django ドキュメント | Django
- クラスベースビュー入門 | Django ドキュメント | Django

デコレータ以外のコードは先ほどのものと同じ内容です。

shop/views.py（ビュー）

from django.db import transaction
from django.http.response import HttpResponseRedirect
from django.shortcuts import get_object_or_404, reverse
from django.utils.decorators import method_decorator  # 追加from django.views import View

from .models import Book, BookStock, Order


@method_decorator(transaction.non_atomic_requests, name='dispatch')  # 追加classCheckoutView(View):
    ...（略）...

    defpost(self, request, *args, **kwargs):
        book = get_object_or_404(Book, pk=kwargs['pk'])

        with transaction.atomic():
            # ① 注文情報を登録
            order = Order(
                status=Order.STATUS_PAYMENT_PROCESSING,
                total_amount=book.price,
                ordered_by=request.user,
            )
            order.save()

            # ② 在庫数を確認
            book_stock = get_object_or_404(BookStock, book=book)
            # ③ 在庫数を1減らして更新
            book_stock.quantity -= 1
            book_stock.save()

        ...（決済処理）...

        with transaction.atomic():
            # ④ 注文情報のステータスを更新
            order.status = Order.STATUS_PAYMENT_OK
            order.save()

        ...（略）...

        return HttpResponseRedirect(reverse('shop:checkout_complete'))

こうすることで、特定のビュー内で ATOMIC_REQUESTS の効果を無効にして、自前でトランザクションを切ることができます。

[pid-1] SET TIME ZONE 'UTC'
[pid-1] SELECT "book"."id", "book"."title", "book"."price", "book"."updated_at" FROM "book" WHERE "book"."id" = 1 LIMIT 21
[pid-1] SELECT "stock"."id", "stock"."book_id", "stock"."quantity", "stock"."updated_at" FROM "stock" WHERE "stock"."book_id" = 1 LIMIT 21
[pid-1] BEGIN
[pid-1] UPDATE "stock" SET "book_id" = 1, "quantity" = 0, "updated_at" = '2020-12-01T03:06:00.940420+00:00'::timestamptz WHERE "stock"."id" = 1
[pid-1] INSERT INTO "order" ("status", "total_amount", "ordered_by_id", "ordered_at") VALUES ('01', 1000, 1, '2020-12-01T03:06:00.945405+00:00'::timestamptz) RETURNING "order"."id"
[pid-1] COMMIT
[pid-1] BEGIN
[pid-1] UPDATE "order" SET "status" = '02', "total_amount" = 1000, "ordered_by_id" = 1, "ordered_at" = '2020-12-01T03:06:00.945405+00:00'::timestamptz WHERE "order"."id" = 4
[pid-1] COMMIT

まとめ

Django はデフォルトではトランザクションを利用しておらず、すべてのクエリ操作が逐一コミットされます。Django でトランザクションを利用するには、大きく「ATOMIC_REQUESTS を有効化する」方法と「transaction.atomic() で囲む」方法の二つがあります。前者は導入が超簡単ですが、性能面での影響を考慮する必要があります。

ちなみに Django が提供しているトランザクションの API は今回紹介したものだけではありません。詳しい説明については 公式ドキュメントの後半部分をお読みください。なお、DjangoCongress JP 2019 の Denzow さんの「どうなってるの？Djangoのトランザクション」の資料が分かりやすいのでぜひ合わせて参照ください。

speakerdeck.com

宣伝

Django の技術同人誌をこれまでに４冊出しました。開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第１弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文180ページ。

★ Amazon（電子版／ペーパー版）

現場で使える Django の教科書《基礎編》

横瀬 明仁 ／ NextPublishing Authors Press (2018/8/26)

Amazon

Kindle

★ BOOTH（ペーパー版）

現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第２弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。

★ Amazon（電子版）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」（通称「DRF」）にフォーカスした、「現場で使える Django の教科書」シリーズの第３弾。B5・本文204ページ。

★ Amazon（電子版）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django 管理サイトのつくり方

Django の管理サイト（Django Admin）だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。

★ Amazon（電子版）

現場で使える Django 管理サイトのつくり方 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International, Inc.

Kindle

★ BOOTH（ペーパー版）

はじめに

複数ユーザからほぼ同じタイミングで同じレコードに対して更新をおこなうと、タイミングによってはレースコンディション（競合状態）が発生してしまい、更新内容が上書きされてしまうことがあります。

次の図を見てください。

一例として、決済処理の中で在庫テーブルを 1 ずつ減らして更新する処理を抜き出したものです。Aさんが在庫テーブルを参照（①）して更新（③）するまでのわずかな時間の中に、Bさんからの在庫テーブルの参照（②）が挟まっている状況を示しています。AさんとBさんが在庫テーブルを参照した時点（① および ②）では双方とも在庫数が「1」となっているのですが、Aさんが在庫テーブルを更新した③のタイミングで在庫数が「0」になるのにも関わらず、Bさんがレコードを「0」に更新（すなわち上書き）できてしまっています。なんと、在庫が「1」だったにも関わらず、二回も購入ができてしまっているのです。

これがレースコンディション（競合状態）です。解決方法としては「排他制御」と呼ばれる対策が採られることが多いです。中でも、更新時にデータが最新のものかどうかをチェックして、データが最新でない場合にエラーを出してレコードを更新しないようにする方式のものを特に「楽観的排他制御」と呼びます。

楽観的排他制御と悲観的排他制御

排他制御には、「楽観的排他制御」（楽観ロック）と「悲観的排他制御」（悲観ロック）があります。特徴や違いについては参考記事に譲ります。

参考

• 排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
• アプリにおける排他制御 -楽観的/悲観的ロックの違いと使い所- - Qiita
• How to manage concurrency in Django models | by Haki Benita | Medium
• Django: How can I protect against concurrent modification of database entries - Stack Overflow

引用してまとめるとこうなります。

楽観的排他制御

• 更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式
• データ取得時の最終更新日時またはバージョン番号を条件に含めて更新する
• 同時更新されることがあまりない場合に使う

悲観的排他制御

• 更新対象のデータを取得する際にロックをかけることで、他のトランザクションから更新されないようにする方式
• 「SELECT FOR UPDATE」を使う
• 同時更新されることが多く、トランザクションが短い場合に使う

　
Django でも「SELECT ... FOR UPDATE」を使うことができますが、本記事では比較的実装が簡単な「楽観的排他制御」の具体的な実装方法について説明します。

次に、データベースのトランザクション分離レベル（isolation level）の話をします。

READ COMMITTED の挙動

Django においては、データベースのトランザクション分離レベルは「READ COMMITTED」がベストとされていて、データベース接続設定のデフォルトのトランザクション分離レベルも「READ COMMITTED」となっています。*1

ちなみに、Django 2.0 以降、MySQL をバックエンドにした場合の分離レベルのデフォルト設定も「READ COMMITTED」に変更になりました。MySQL（InnoDB）自体のデフォルトのトランザクション分離レベルは「REPEATABLE READ」ですが、もしそれに合わせたい場合は、Django 側のデータベースオプションで明示的に

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        ...
        'OPTIONS': {
            ...
            'isolation_level': 'REPEATABLE READ',
        }
    }
}

として、「isolation_level」の指定をしないといけません。

「READ COMMITTED」のトランザクション内では、「REPEATABLE READ」とは異なり、他のトランザクションのコミットによる変更が参照できます。例えば、次の図のように、他のユーザのトランザクションが終了した瞬間から最新の値が参照できるようになっています。

つまり、「READ COMMITTED」では、更新するギリギリのタイミングで最新のデータを参照することでレースコンディション（競合状態）を起こしにくくすることができると言えるでしょう。

これを踏まえた上で、楽観的排他制御の具体的な実装方法としては、例えばモデルにバージョンを保持するフィールドを追加し、データが更新されるたびに値をインクリメントして更新するようにします。そして更新の際にバージョンの値を検索条件に含め、更新件数が0件となった場合に排他エラーを発生させます。このような仕組みを自前で実装してもよいのですが、django-concurrencyパッケージを利用すると簡単に実装することができます。

django-concurrency パッケージを利用する

django-concurrencyパッケージを利用すると、楽観的排他制御が簡単に実現できます。

まず、pip で django-concurrency をインストールします。

(venv) > pip install django-concurrency==2.2.*

あとは、排他制御したいモデルに次のように concurrency.fields.AutoIncVersionField を使って「version」フィールドを追加するだけです。

shop/models.py（モデル）

from concurrency.fields import AutoIncVersionField  # 追加from django.db import models


classBook(models.Model):
    """本モデル"""classMeta:
        db_table = 'book'
        verbose_name = verbose_name_plural = '本'

    title = models.CharField('タイトル', max_length=255, unique=True)
    price = models.PositiveIntegerField('価格', null=True, blank=True)

    def__str__(self):
        return self.title


classBookStock(models.Model):
    """在庫モデル"""classMeta:
        db_table = 'stock'
        verbose_name = verbose_name_plural = '在庫'

    book = models.OneToOneField(Book, verbose_name='本', on_delete=models.CASCADE)
    quantity = models.PositiveIntegerField('在庫数', default=0)
    updated_at = models.DateTimeField('更新日時', auto_now=True)
    version = AutoIncVersionField(verbose_name='バージョン')   # 追加def__str__(self):
        return f'{self.book.title} ({self.quantity})'

AutoIncVersionField は初回登録時に初期値「1」で自動保存され、更新するたびに自動でインクリメントされていきます。以下は Django シェル環境での実行例です。

>>> s1 = BookStock.objects.create(book_id=1, quantity=10)
>>> s1.version
1
>>> s1.save()
>>> s1.version
2

レコードの更新時にはバージョンの値が更新条件に自動的に加えられ、条件に合致しない場合は更新件数が0件になり、RecordModifiedError が発生します。

>>> s2 = BookStock.objects.get(book_id=1)
>>> s2.version
2
>>> s1.save()
>>> s1.version
3
>>> s2.save()
Traceback (most recent call last):
  ...（略）...
concurrency.exceptions.RecordModifiedError: Record has been modified

先ほどの決済処理の例では次のようにBさんの処理がエラーになり、更新ができなくなります。

「ATOMIC_REQUESTS」や「transaction.atomic() 」でトランザクションを利用していて、RecordModifiedError がトランザクション内でキャッチされなかった場合はトランザクションがロールバックされます。

PostgreSQL の SQL ログの例は次のようになります（「pid-1」および「pid2」はプロセス番号を分かりやすいように書き換えたものです）。

《 PostgreSQL の SQL ログ 》

12:00:11.976 JST [pid-1] SET TIME ZONE 'UTC'
12:00:11.980 JST [pid-1] SELECT "book"."id", "book"."title", "book"."price" FROM "book" WHERE "book"."id" = 1 LIMIT 21
12:00:11.984 JST [pid-1] BEGIN
12:00:11.986 JST [pid-1] INSERT INTO "order" ("status", "total_amount", "ordered_by_id", "ordered_at") VALUES ('01', 1000, 1, '2020-12-01T03:00:11.983496+00:00'::timestamptz) RETURNING "order"."id"
12:00:11.992 JST [pid-1] SELECT "stock"."id", "stock"."book_id", "stock"."quantity", "stock"."updated_at", "stock"."version" FROM "stock" WHERE "stock"."book_id" = 1 LIMIT 21

12:00:12.011 JST [pid-2] SET TIME ZONE 'UTC'
12:00:12.013 JST [pid-2] SELECT "book"."id", "book"."title", "book"."price" FROM "book" WHERE "book"."id" = 1 LIMIT 21
12:00:12.019 JST [pid-2] BEGIN
12:00:12.020 JST [pid-2] INSERT INTO "order" ("status", "total_amount", "ordered_by_id", "ordered_at") VALUES ('01', 1000, 1, '2020-12-01T03:00:12.016340+00:00'::timestamptz) RETURNING "order"."id"
12:00:12.028 JST [pid-2] SELECT "stock"."id", "stock"."book_id", "stock"."quantity", "stock"."updated_at", "stock"."version" FROM "stock" WHERE "stock"."book_id" = 1 LIMIT 21

12:00:13.109 JST [pid-1] SELECT (1) AS "a" FROM "stock" WHERE "stock"."id" = 1 LIMIT 1
12:00:13.112 JST [pid-1] UPDATE "stock" SET "book_id" = 1, "quantity" = 0, "updated_at" = '2020-12-01T03:00:13.106776+00:00'::timestamptz, "version" = 2 WHERE ("stock"."id" = 1 AND "stock"."version" = 1)
12:00:13.115 JST [pid-1] COMMIT
12:00:13.124 JST [pid-1] BEGIN
12:00:13.126 JST [pid-1] UPDATE "order" SET "status" = '02', "total_amount" = 1000, "ordered_by_id" = 1, "ordered_at" = '2020-12-01T03:00:11.983496+00:00'::timestamptz WHERE "order"."id" = 55
12:00:13.128 JST [pid-1] COMMIT

12:00:14.412 JST [pid-2] SELECT (1) AS "a" FROM "stock" WHERE "stock"."id" = 1 LIMIT 1
12:00:14.417 JST [pid-2] UPDATE "stock" SET "book_id" = 1, "quantity" = 0, "updated_at" = '2020-12-01T03:00:14.409133+00:00'::timestamptz, "version" = 2 WHERE ("stock"."id" = 1 AND "stock"."version" = 1)
12:00:14.419 JST [pid-2] ROLLBACK

UPDATE 時に version の値が検索条件として加えられているのが確認できます。「pid-2」の UPDATE 時にRecordModifiedError が発生し、トランザクションがロールバックされています。

django-concurrency の「concurrency.middleware.ConcurrencyMiddleware」というミドルウェアを使うことで、独自の排他エラー画面に遷移させることも可能です。

config/settings.py（設定ファイル）

MIDDLEWARE = [
    'concurrency.middleware.ConcurrencyMiddleware',  # 追加'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

ConcurrencyMiddleware には ビューから例外が漏れたとき実行される process_exception が実装されていて、例外クラスが RecordModifiedError の場合に「concurrency.views.conflict」というコールバックが呼ばれ、最終的に「409.html」という名前のテンプレートがレンダリングされるような作りになっています。

そこで、設定ファイルの「TEMPLATES」の設定を次のように修正した上で、

config/settings.py（設定ファイル）

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [BASE_DIR / 'templates'],  # 修正'APP_DIRS': True,
        ...（略）...
    },
]

BASE_DIR の直下の「templates」ディレクトリの下に 409.html を配置しておくと、排他エラー発生時にこの画面に遷移させることが可能です（templates/base.html のコードは省略）。

templates/409.html

{% extends "base.html" %}

{% block title %}排他エラー{% endblock %}

{% block content %}
<h3>排他エラー</h3><hr><p>排他エラーが発生しました。</p>
{% endblock %}

排他制御エラー発生時のコールバック関数をカスタマイズすることも可能です。公式ドキュメントに書かれている通り、設定ファイルに「CONCURRENCY_HANDLER409」を定義します。

config/settings.py（設定ファイル）

MIDDLEWARE = [
    'concurrency.middleware.ConcurrencyMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

CONCURRENCY_HANDLER409 = 'common.handlers.conflict'# 追加

common/handlers.py

from django.shortcuts import render

from shop.models import BookStock


defconflict(request, target=None, template_name='409.html'):
    ifisinstance(target, BookStock):
        template_name = 'shop/book_stock_conflict.html'try:
        saved = target.__class__._default_manager.get(pk=target.pk)
    except target.__class__.DoesNotExists:
        saved = None

    context = {
        'target': target,  # 更新しようとしたモデルオブジェクト'saved': saved,  # 最新状態のモデルオブジェクト
    }
    return render(request, template_name, context)

templates/shop/book_stock_conflict.html

{% extends "base.html" %}

{% block title %}排他エラー{% endblock %}

{% block content %}
<h3>排他エラー</h3><hr><p>在庫レコードの更新時に排他エラーが発生しました。</p>
{% endblock %}

なお、disable_concurrencyをデコレータや with 句で利用することで、特定のビューやモデル操作に対して排他制御をしないようにすることもできます。またこの django-concurrency は、管理サイトや Django REST Framework（DRF）でも利用できるので大変便利です。

まとめ

複数ユーザからほぼ同じタイミングで同じレコードに対して更新をおこなうと、タイミングによってはレースコンディション（競合状態）が発生し、更新内容が上書きされてしまうことがあります。レースコンディションが業務にクリティカルな影響を与えてしまう場合は排他制御が必要になります。

Django で楽観的排他制御を実現するには、django-concurrency パッケージを利用すれば非常に簡単に実装することができます。

宣伝

Django の技術同人誌をこれまでに４冊出しました。開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第１弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文180ページ。

★ Amazon（電子版／ペーパー版）

現場で使える Django の教科書《基礎編》

横瀬 明仁 ／ NextPublishing Authors Press (2018/8/26)

Amazon

Kindle

★ BOOTH（ペーパー版）

現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第２弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。

★ Amazon（電子版）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」（通称「DRF」）にフォーカスした、「現場で使える Django の教科書」シリーズの第３弾。B5・本文204ページ。

★ Amazon（電子版）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django 管理サイトのつくり方

Django の管理サイト（Django Admin）だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。

★ Amazon（電子版）

現場で使える Django 管理サイトのつくり方 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International, Inc.

Kindle

★ BOOTH（ペーパー版）

はじめに

あまり知られていないかもしれませんが、Django でもデータベースビューを扱うことができます。具体的には、データベースビューに対応するモデルを用意することで、データベースビューのレコードをモデルオブジェクトとして取り扱うことができます（しかし当然ながら、データベースビューへのレコードの登録や更新、削除はできませんのでご注意を）。

ところで、データベースビューを使うと何が嬉しいのでしょうか？

例えば、テーブルの結果を 集計したり、サブクエリを使ったり、複数のテーブルを UNIONしたりするには、Django ORM の API を使って実現できないこともありませんが、コードが複雑になり、思わぬバグが混入する可能性が高くなってしまいます。それならいっそのこと SQL で書いてしまう方が早くて確実だというケースもあるでしょう。そんなときにデータベースビューを使えば、モデル側のコードをすっきりさせることができるのです。 *1

データベースビューに対応するモデル

通常のモデルとの違いは、Meta に「managed = False」を指定するだけです。これで、モデルをマイグレーションの対象外にすることができます。*2

次の例を見てください。

sales/models.py（モデル）

from django.db import models


classSalesResultPerMonth(models.Model):
    classMeta:
        managed = False
        db_table = 'sales_result_per_month'
        verbose_name = verbose_name_plural = '月別合計売上金額'

    sales_month = models.DateField('売上月')
    total_amount = models.PositiveIntegerField('合計売上金額')
    target_amount = models.PositiveIntegerField('目標売上金額')

モデルの Meta クラスに「managed = False」を指定しています。ちなみにデータベースビューに対応したモデルには「null=True」や「blank=True」などのフィールドオプションは付ける必要はありません。データベースビューには登録や更新ができないため、付けてもあまり意味がないからです。

モデルをマイグレーションの対象外にすると、マイグレーション（migrate）コマンドを実行したときにマイグレーションファイルの内容がデータベースのテーブルに反映されず、テーブルが新たに作成されたり、テーブル構造が変更されたりすることがなくなります。

具体例

簡単な例として、売上実績テーブルから月次の売上金額の合計を集計して、売上目標テーブルの売上目標金額と比較することを取り上げてみます。これをデータベースビューとして利用するイメージは次のようになります。

通常のモデルを作成する

まず、sales アプリケーションに「売上目標モデル」と「売上実績モデル」を次のように定義します。これらはマイグレーション対象となる通常のモデルです。

sales/models.py（モデル）

from django.db import models


classSalesTarget(models.Model):
    """売上目標モデル"""classMeta:
        db_table = 'sales_target'
        verbose_name = verbose_name_plural = '売上目標'

    sales_month = models.DateField('売上月')
    amount = models.PositiveIntegerField('目標金額')
    created_at = models.DateTimeField('登録日時', auto_now_add=True)

    def__str__(self):
        return f'{self.sales_month:%Y年%m月}'classSalesResult(models.Model):
    """売上実績モデル"""classMeta:
        db_table = 'sales_result'
        verbose_name = verbose_name_plural = '売上実績'

    sales_date = models.DateField('売上日')
    amount = models.PositiveIntegerField('売上金額')
    subject = models.CharField('件名', max_length=255)
    created_at = models.DateTimeField('登録日時', auto_now_add=True)

    def__str__(self):
        return f'{self.sales_date:%Y年%m月%d日} - {self.subject}'

makemigrations コマンドでマイグレーションファイルを作成して、migrate コマンドでマイグレーションを実行すると、次のようなテーブルが作成されます。

(venv) > python manage.py makemigrations sales
(venv) > python manage.py migrate sales

データベースビュー作成用の DDL をマイグレーションファイルに書く

データベースビューを作成するための DDL は、マイグレーションファイルに書くのがよいでしょう。次のように「--empty」オプションを付けて makemigrations コマンドを実行すると、空のマイグレーションファイルを作成することができます。

(venv) $ python manage.py makemigrations sales --empty

上記のコマンドを実行すると、次のようなマイグレーションファイルが「sales/migrations」ディレクトリの下に生成されます。

sales/migrations/0002_auto_20201204_2134.py（マイグレーションファイル）

# Generated by Django 3.1.3 on 2020-12-04 12:34from django.db import migrations


classMigration(migrations.Migration):

    dependencies = [
        ('sales', '0001_initial'),
    ]

    operations = [
    ]

このひな型ファイルを次のように編集して、sales_result_per_month ビューを作成する DDL を書き加えます。

# Generated by Django 3.1.3 on 2020-12-04 12:34from django.db import migrations


classMigration(migrations.Migration):

    dependencies = [
        ('sales', '0001_initial'),
    ]

    sql = """        CREATE VIEW sales_result_per_month AS            SELECT                ROW_NUMBER() OVER() AS id,                t.sales_month,                t.amount AS target_amount,                SUM(r.amount) AS total_amount            FROM                sales_target t            LEFT OUTER JOIN                sales_result r            ON                TO_CHAR(t.sales_month, 'YYYY-MM') = TO_CHAR(r.sales_date, 'YYYY-MM')            GROUP BY                t.sales_month, t.amount            ORDER BY                t.sales_month;"""

    reverse_sql = """        DROP VIEW IF EXISTS sales_result_per_month;"""

    operations = [
        migrations.RunSQL(sql, reverse_sql),
    ]

RunSQL の第一引数には migrate コマンドが実行されたときに発行する SQL を、第二引数には特定のバージョンのマイグレーションの状態に戻す *3ときに発行する SQL を指定します（第二引数は省略可）。ちなみにこの SQL は PostgreSQL 向けのものです。

マイグレーションファイルを手動で書くやり方については、次の記事を参考にしてみてください。

参考

• マイグレーション | Django ドキュメント | Django
• Django マイグレーション完全に理解した (ケーススタディ編) 🍎 - くろのて

マイグレーションを実行すると、データベースビューが作成されます。

(venv) $ python manage.py migrate sales

pgAdmin 4 上で確認すると、このようになっています。

from django.db import models


classSalesTarget(models.Model):
    """売上目標モデル"""
    ...（略）...


classSalesResult(models.Model):
    """売上実績モデル"""
    ...（略）...


classSalesResultPerMonth(models.Model):  # 追加"""月別合計売上金額モデル"""classMeta:
        managed = False
        db_table = 'sales_result_per_month'
        verbose_name = verbose_name_plural = '月別合計売上金額'

    sales_month = models.DateField('売上月')
    total_amount = models.PositiveIntegerField('合計売上金額')
    target_amount = models.PositiveIntegerField('目標売上金額')

(venv) > python manage.py inspectdb sales_result_per_month

# This is an auto-generated Django model module.# You'll have to do the following manually to clean this up:#   * Rearrange models' order#   * Make sure each model has one field with primary_key=True#   * Make sure each ForeignKey and OneToOneField has `on_delete` set to the desired behavior#   * Remove `managed = False` lines if you wish to allow Django to create, modify, and delete the table# Feel free to rename the models, but don't rename db_table values or field names.from django.db import models


classSalesResultPerMonth(models.Model):
    id = models.BigIntegerField(blank=True, null=True)
    sales_month = models.DateField(blank=True, null=True)
    target_amount = models.IntegerField(blank=True, null=True)
    total_amount = models.BigIntegerField(blank=True, null=True)

    classMeta:
        managed = False# Created from a view. Don't remove.
        db_table = 'sales_result_per_month'

管理サイトでデータベースビューの内容を確認する

最後に、このデータベースビューの内容を管理サイト上で確認できるようにしてみましょう。sales/admin.py を次のように編集します。

sales/admin.py（管理サイト用モジュール）

from django.contrib import admin

from common.helpers.admin_helper import format_yen, format_yyyy_nen_mm_gatsu
from .models import SalesResult, SalesResultPerMonth, SalesTarget


classSalesResultAdmin(admin.ModelAdmin):
    """売上実績モデル用 ModelAdmin"""################################ モデル一覧画面のカスタマイズ###############################
    list_display = ('sales_date', 'format_amount', 'subject')
    ordering = ('sales_date', 'created_at')

    defformat_amount(self, obj):
        return format_yen(obj.amount)

    format_amount.short_description = '売上金額'
    format_amount.admin_order_field = 'amount'################################ モデル追加・変更画面のカスタマイズ###############################
    readonly_fields = ('id', 'created_at')


classSalesTargetAdmin(admin.ModelAdmin):
    """売上目標モデル用 ModelAdmin"""################################ モデル一覧画面のカスタマイズ###############################
    list_display = ('format_sales_month', 'format_amount')
    ordering = ('sales_month',)

    defformat_sales_month(self, obj):
        return format_yyyy_nen_mm_gatsu(obj.sales_month)

    format_sales_month.short_description = '売上月'
    format_sales_month.admin_order_field = 'sales_month'defformat_amount(self, obj):
        return format_yen(obj.amount)

    format_amount.short_description = '目標金額'
    format_amount.admin_order_field = 'amount'################################ モデル追加・変更画面のカスタマイズ###############################
    readonly_fields = ('id', 'created_at')


classSalesResultPerMonthAdmin(admin.ModelAdmin):
    """月別合計売上金額モデル用 ModelAdmin"""################################ モデル一覧画面のカスタマイズ###############################
    list_display = ('format_sales_month', 'format_target_amount', 'format_total_amount')
    ordering = ('sales_month',)

    defformat_sales_month(self, obj):
        return format_yyyy_nen_mm_gatsu(obj.sales_month)

    format_sales_month.short_description = '売上月'
    format_sales_month.admin_order_field = 'sales_month'defformat_target_amount(self, obj):
        return format_yen(obj.target_amount)

    format_target_amount.short_description = '目標売上金額'
    format_target_amount.admin_order_field = 'target_amount'defformat_total_amount(self, obj):
        return format_yen(obj.total_amount)

    format_total_amount.short_description = '合計売上金額'
    format_total_amount.admin_order_field = 'total_amount'################################ その他のカスタマイズ###############################defhas_add_permission(self, request):
        returnFalsedefhas_change_permission(self, request, obj=None):
        returnFalsedefhas_delete_permission(self, request, obj=None):
        returnFalse


admin.site.register(SalesTarget, SalesTargetAdmin)
admin.site.register(SalesResult, SalesResultAdmin)
admin.site.register(SalesResultPerMonth, SalesResultPerMonthAdmin)

管理サイトの月別合計売上金額モデルの一覧画面はこのように表示されます。

何がどうなっているのか？が気になる方は、拙著『現場で使える Django 管理サイトのつくり方』にいろいろと書いてあるので、ぜひお手に取ってご確認くださいませ 🙇

akiyoko.hatenablog.jp

　

（おまけ）マイグレーションファイルの SQL を複数種類のデータベースに対応させる方法

例示したマイグレーションファイルの SQL は PostgreSQL だけにしか使えません。PostgreSQL を使うだけならこれでもよいのですが、ローカルでは SQLite を使って、本番環境では PostgreSQL を使って・・といったケースには対応できません。そのような場合は、RunPython を使って次のように書き分けることができます。

# Generated by Django 3.1.3 on 2020-12-04 12:34from django.db import migrations
from django.db.migrations import exceptions


defcode(apps, schema_editor):
    if schema_editor.connection.vendor == 'sqlite':
        schema_editor.execute("""            CREATE VIEW sales_result_per_month AS                SELECT                    ROW_NUMBER() OVER() AS id,                    t.sales_month,                    t.amount AS target_amount,                    SUM(r.amount) AS total_amount                FROM                    sales_target t                LEFT OUTER JOIN                    sales_result r                ON                    STRFTIME('%Y-%m', t.sales_month) = STRFTIME('%Y-%m', r.sales_date)                GROUP BY                    t.sales_month                ORDER BY                    sales_month;""")
    elif schema_editor.connection.vendor == 'postgresql':
        schema_editor.execute("""            CREATE VIEW sales_result_per_month AS                SELECT                    ROW_NUMBER() OVER() AS id,                    t.sales_month,                    t.amount AS target_amount,                    SUM(r.amount) AS total_amount                FROM                    sales_target t                LEFT OUTER JOIN                    sales_result r                ON                    TO_CHAR(t.sales_month, 'YYYY-MM') = TO_CHAR(r.sales_date, 'YYYY-MM')                GROUP BY                    t.sales_month, t.amount                ORDER BY                    t.sales_month;""")
    elif schema_editor.connection.vendor == 'mysql':
        schema_editor.execute("""            CREATE VIEW sales_result_per_month AS                SELECT                    ROW_NUMBER() OVER() AS id,                    t.sales_month,                    t.amount AS target_amount,                    SUM(r.amount) AS total_amount                FROM                    sales_target t                LEFT OUTER JOIN                    sales_result r                ON                    DATE_FORMAT(t.sales_month, '%Y-%m') = DATE_FORMAT(r.sales_date, '%Y-%m')                GROUP BY                    t.sales_month;                ORDER BY                    t.sales_month;""", params=None)
    else:
        raise exceptions.BadMigrationError(
            'Database vendor should be SQLite, PostgreSQL, or MySQL.')


defreverse_code(apps, schema_editor):
    schema_editor.execute('DROP VIEW IF EXISTS sales_result_per_month;')


classMigration(migrations.Migration):
    dependencies = [
        ('sales', '0001_initial'),
    ]

    operations = [
        migrations.RunPython(code, reverse_code, atomic=False)
    ]

まとめ

モデルの Meta クラスに「managed = False」を指定すると、マイグレーションの対象から外すことができるため、データベースビューに対応するモデルを作成することができます。

またこの方法を利用すれば、すでにあるテーブルに対応するモデルを作成することも可能です。いろいろ便利に使えそうですね！

宣伝

Django の技術同人誌をこれまでに４冊出しました。開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第１弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文180ページ。

★ Amazon（電子版／ペーパー版）

現場で使える Django の教科書《基礎編》

横瀬 明仁 ／ NextPublishing Authors Press (2018/8/26)

Amazon

Kindle

★ BOOTH（ペーパー版）

現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第２弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。

★ Amazon（電子版）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」（通称「DRF」）にフォーカスした、「現場で使える Django の教科書」シリーズの第３弾。B5・本文204ページ。

★ Amazon（電子版）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django 管理サイトのつくり方

Django の管理サイト（Django Admin）だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。

★ Amazon（電子版）

現場で使える Django 管理サイトのつくり方 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International, Inc.

Kindle

★ BOOTH（ペーパー版）

はじめに

Django REST Framework には、API スキーマ（どのような URL にどのようなリクエストを送ればどのようなレスポンスが返ってくるかという API の定義を記述したもの）を出力してくれる「API ドキュメンテーション」機能が備わっています。

DRF 公式ドキュメント

• Schemas - Django REST framework
• Documenting your API - Django REST framework

API スキーマの仕様は「OpenAPI 3.0」に準拠しています。「OpenAPI 3.0」は、REST API インタフェース記述の標準化を目指して Swagger 2.0 を統合して策定された仕様です。

swagger.io

OpenAPI スキーマファイル（YAML形式）の例を次に示します。

openapi:"3.0.0"info:title: Simple API overview
  version: 2.0.0
paths:/:get:operationId: listVersionsv2
      summary: List API versions
      responses:'200':description: |-
            200 response
          content:application/json:examples:foo:value:{"versions":[{"status":"CURRENT",
                            "updated":"2011-01-21T11:33:21Z",
                            "id":"v2.0",
                            "links":[{"href":"http://127.0.0.1:8774/v2/",
                                    "rel":"self"}]},
                        {"status":"EXPERIMENTAL",
                            "updated":"2013-07-23T11:33:21Z",
                            "id":"v3.0",
                            "links":[{"href":"http://127.0.0.1:8774/v3/",
                                    "rel":"self"}]}]}

...（略）...

https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v3.0/api-with-examples.yamlより引用

【方法１】DRF 標準の generateschema コマンドを使ってスキーマファイルを出力する

DRF 標準の generateschema コマンドを使って OpenAPI スキーマファイルを出力するには、PyYAML パッケージと uritemplate パッケージが必要です。

そこで、次のようにして PyYAML と uritemplate をそれぞれインストールします。

(venv) > pip install PyYAML==5.3.* uritemplate==3.0.*

次のように generateschema コマンドを実行すれば、OpenAPI 3.0 に対応した YAML形式のスキーマファイルを出力することができます。ちなみに format オプションで「openapi-json」を指定すれば、JSON 形式のファイルを出力することも可能です。

(venv) > python manage.py generateschema --file schema.yml

コマンドを実行すると、次のようなスキーマファイルが出力されます。

openapi: 3.0.2
info:title:''version:''paths:/api/v0/books/:get:operationId: listBookListCreates
      description:"\u672C\u30E2\u30C7\u30EB\u306E\u53D6\u5F97\uFF08\u4E00\u89A7\uFF09\        API\u306B\u5BFE\u5FDC\u3059\u308B\u30CF\u30F3\u30C9\u30E9\u30E1\u30BD\u30C3\
        \u30C9"
      parameters:[]responses:'200':content:application/json:schema:type: array
                items:{}description:''tags:- api

      ...（略）...

出力したスキーマファイルを、OpenAPI に対応した Swagger Editorや Swagger Inspectorなどのツールに読み込ませて、ツール上で API の定義を確認したり、API クライアント（API へのリクエストを実行できるツール）として利用したりすることができます。

オンライン API ドキュメントエディタ Swagger Editor の画面例

Swagger Inspector の画面例

このほかにも OpenAPI スキーマファイルが利用できるツールは多数存在します。

openapi.tools

公式ドキュメントでは、URLconf やテンプレートの準備をして Swagger UI と ReDoc の二種類の API ドキュメント画面を表示させる方法を紹介していますが、次に示す drf-spectacularを利用する方が簡単なので筆者はそちらを推します（公式ドキュメントでも代替案として drf-spectacular を紹介しています）。

【方法２】drf-spectacular を利用する

これまで DRF で標準になっていた CoreAPI ベースの「AutoSchema」を使えば、次のような API ドキュメント画面を簡単に構築することができました。*3

しかし先述のように、CoreAPI ベースの「AutoSchema」の利用は非推奨になってしまいました。そこで、代わりに「drf-spectacular」を利用すれば、OpenAPI 3.0 準拠の API スキーマファイルを出力できるのに加えて、Swagger UI 形式と ReDoc 形式の二種類の API ドキュメント画面を自動生成することができます。

(venv) > pip install drf-spectacular==0.11.*

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

    # 3rd party apps'drf_spectacular',  # 追加

    ...
]

...

REST_FRAMEWORK = {
    'DEFAULT_SCHEMA_CLASS': 'drf_spectacular.openapi.AutoSchema',  # 追加
}

(venv) > python manage.py spectacular --file schema.yml

from django.urls import include, path
from drf_spectacular.views import SpectacularAPIView, SpectacularRedocView, SpectacularSwaggerView  # 追加

urlpatterns = [
    ...（略）...
]

if settings.DEBUG:
    urlpatterns += [
        path('api/schema/', SpectacularAPIView.as_view(), name='schema'),                                      # 追加
        path('api/schema/swagger-ui/', SpectacularSwaggerView.as_view(url_name='schema'), name='swagger-ui'),  # 追加
        path('api/schema/redoc/', SpectacularRedocView.as_view(url_name='schema'), name='redoc'),              # 追加
    ]

Swagger UI 形式の APIドキュメント画面

設定完了後に runserver を起動し、（起動 URL が「127.0.0.1:8000」の場合）ブラウザで「http://127.0.0.1:8000/api/schema/swagger-ui/」にアクセスすれば、Swagger UI 形式の APIドキュメント画面が表示できます。

API ごとの「Try it out」ボタンをクリックして、「Parameters」を適宜入力して「Execute」ボタンをクリックすることでリクエストを送信することができるので、API クライアントとしても利用することができます。

　

ReDoc 形式の APIドキュメント画面

ReDoc 形式の APIドキュメント画面（http://127.0.0.1:8000/api/schema/redoc/）は次のようになります。

　

from drf_spectacular.utils import extend_schema
from rest_framework import status, views
from rest_framework.response import Response

from shop.models import Book
from .serializers import BookSerializer


classBookListCreateAPIView(views.APIView):
    """本モデルの取得（一覧）・登録APIクラス"""@extend_schema(
        responses={200: BookSerializer},
    )
    defget(self, request, *args, **kwargs):
        """本モデルの取得（一覧）APIに対応するハンドラメソッド"""

        ...（略）...

        return Response(serializer.data, status.HTTP_200_OK)

    @extend_schema(
        request=BookSerializer,
        responses={201: BookSerializer},
    )
    defpost(self, request, *args, **kwargs):
        """本モデルの登録APIに対応するハンドラメソッド"""

        ...（略）...

        return Response(serializer.data, status.HTTP_201_CREATED)

まとめ

Django REST Framework（DRF）にはデフォルトで OpenAPI 3.0 に対応した API スキーマを出力してくれる「API ドキュメンテーション」機能が備わっています。利用方法は簡単で、generateschema コマンドでスキーマファイルを出力するだけです（ただし、PyYAML と uritemplate のインストールが必要）。

API スキーマをリアルタイムに反映した API ドキュメント画面を表示したいのであれば、drf-spectacular パッケージを利用するのが簡単です。なお、DRF 3.12 以降は、DRF 3.10 までで標準だった CoreAPI ベースの APIドキュメント画面が利用できなくなるので注意が必要です。

宣伝

Django の技術同人誌をこれまでに４冊出しました。開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第１弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文180ページ。

★ Amazon（電子版／ペーパー版）

現場で使える Django の教科書《基礎編》

横瀬 明仁 ／ NextPublishing Authors Press (2018/8/26)

Amazon

Kindle

★ BOOTH（ペーパー版）

現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第２弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。

★ Amazon（電子版）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」（通称「DRF」）にフォーカスした、「現場で使える Django の教科書」シリーズの第３弾。B5・本文204ページ。

★ Amazon（電子版）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

Kindle

★ BOOTH（ペーパー版）

現場で使える Django 管理サイトのつくり方

Django の管理サイト（Django Admin）だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。

★ Amazon（電子版）

現場で使える Django 管理サイトのつくり方 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International, Inc.

Kindle

★ BOOTH（ペーパー版）

はじめに

Django は Webアプリケーションを作成するために必要な機能が何でも揃っているフルスタックフレームワークで、ユーザー認証まわりの機能（ユーザーモデル、パーミッション、ユーザーセッションなど）などの便利な機能がデフォルトで用意されています。そしてあまりよく知られていませんが、パスワード再設定（パスワードリセット）機能（で利用できるビューやフォーム）もユーザー認証まわりの機能の一部として「django.contrib.auth（認証システム）」パッケージに含まれています。

なお、「django.contrib.admin（管理サイト）」パッケージにはパスワード再設定系のテンプレートが用意されているので、管理サイト内でパスワード再設定機能を利用するのは非常に簡単です。

管理サイトでのパスワード再設定機能の利用方法

管理サイトではパスワード再設定系の機能はデフォルトでオフになっているため、利用するには次のように URLconf にパスワード再設定用の4つの URLパターンを追加しなければいけません（詳しくは公式ドキュメント *1を参照）。

config/urls.py（URLconf）

from django.contrib import admin
from django.contrib.auth import views as auth_views
from django.urls import path

urlpatterns = [
    path('admin/password_reset/', auth_views.PasswordResetView.as_view(), name='admin_password_reset'),
    path('admin/password_reset/done/', auth_views.PasswordResetDoneView.as_view(), name='password_reset_done'),
    path('reset/<uidb64>/<token>/', auth_views.PasswordResetConfirmView.as_view(), name='password_reset_confirm'),
    path('reset/done/', auth_views.PasswordResetCompleteView.as_view(), name='password_reset_complete'),
    path('admin/', admin.site.urls),
]

上で示した「admin_password_reset」というURLパターンが登録されていれば、管理サイトのログイン画面に、次のように「パスワードまたはユーザー名を忘れましたか？」というリンクが表示されるようになります。

この追加設定により、次のような画面遷移ができます。

それぞれの挙動は参考情報に示したビューやフォームを読めば分かるのですが、ちょっと理解しずらいのが「パスワード再設定メール」の仕組みです。

パスワード再設定メールの仕組み

パスワード再設定メール送信画面で「パスワードをリセット」ボタンを押下すると、django.contrib.auth.views.PasswordResetView がリクエストを受け取り、入力したメールアドレスに紐付くアクティブ（is_active が True）なユーザーが存在する場合にのみパスワード再設定用のメールが送信されます。

例えばホストが「127.0.0.1:8000」の場合のパスワード再設定メールは次のようになります。

Subject: 127.0.0.1:8000 のパスワードリセット
From: webmaster@localhost
To: admin@example.com
Date: Fri, 26 Nov 2021 21:47:26 -0000
Message-ID: 
 <163796324660.443.3589748126282107509@1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa>
このメールは 127.0.0.1:8000 で、あなたのアカウントのパスワードリセットが要求されたため、送信されました。
次のページで新しいパスワードを選んでください:
http://127.0.0.1:8000/reset/MQ/awrev2-3a07a0471392cfbc3b885b713b2846d5/
あなたのユーザー名 (もし忘れていたら): admin
ご利用ありがとうございました！
 127.0.0.1:8000 チーム

メール本文にはパスワード再設定画面に遷移するためのリンクが含まれており、リンクの有効期限はデフォルトでは3日間となっています。*2

このリンクの URL は、「password_reset_confirm」という URL パターンで URLconf に登録されている「reset/＜uidb64＞/＜token＞/」に相当します。＜uidb64＞の部分、すなわち上のメールの例の「MQ」は、Base64 でエンコードされたユーザーの PK で、Base64 でデコードすると「1」になります。

＜token＞の「-」の左側の部分（上の例では「awrev2」）は、メール送信時のタイムスタンプ（2001/1/1 00:00:00 からの経過秒数）を Base34 でエンコードしたもので、リンクの有効期限をチェックするために使われます。残りの右側の部分（上の例では「3a07a0471392cfbc3b885b713b2846d5」）は改ざん防止のためのハッシュです。*3

django.contrib.auth.views.PasswordResetConfirmView では、パスワード再設定URL のリクエストを受け取ると、URL の妥当性（ユーザーが存在するかどうか、URL が改ざんされていないかどうか、有効期限を過ぎていないか）が検証され、「/reset/＜uidb64＞/set-password/」にリダイレクトされてパスワード再設定画面が表示されます。

ちなみに、URL の＜token＞は（ハッシュ化された）パスワード文字列などから生成されているため（下記参照）、パスワード再設定によってパスワードが変更された後は同じ URL は利用できなくなります。

django.contrib.auth.tokens.PasswordResetTokenGenerator._make_hash_value

def_make_hash_value(self, user, timestamp):
        """        Hash the user's primary key, email (if available), and some user state        that's sure to change after a password reset to produce a token that is        invalidated when it's used:        1. The password field will change upon a password reset (even if the           same password is chosen, due to password salting).        2. The last_login field will usually be updated very shortly after           a password reset.        Failing those things, settings.PASSWORD_RESET_TIMEOUT eventually        invalidates the token.        Running this data through salted_hmac() prevents password cracking        attempts using the reset token, provided the secret isn't compromised."""# Truncate microseconds so that tokens are consistent even if the# database doesn't support microseconds.
        login_timestamp = ''if user.last_login isNoneelse user.last_login.replace(microsecond=0, tzinfo=None)
        email_field = user.get_email_field_name()
        email = getattr(user, email_field, '') or''return f'{user.pk}{user.password}{login_timestamp}{timestamp}{email}'

まとめ

Django はパスワード再設定（パスワードリセット）機能を組み込みで提供しており、管理サイト内でパスワード再設定機能を利用するのは非常に簡単です。管理サイト外でパスワード再設定を利用する場合は、「django.contrib.auth（認証システム）」パッケージのビューやフォームを使用し、「django.contrib.admin（管理サイト）」パッケージのテンプレートを参考にすればよいでしょう。

パスワード再設定系のビューやフォーム、テンプレートについては次の参考情報をご確認ください。

参考情報

パスワード再設定系のビュー・フォーム

• django.contrib.auth.views.PasswordResetView
• django.contrib.auth.views.PasswordResetDoneView
• django.contrib.auth.views.PasswordResetConfirmView
• django.contrib.auth.views.PasswordResetCompleteView

• django.contrib.auth.forms.PasswordResetForm
• django.contrib.auth.forms.SetPasswordForm

パスワード再設定系のテンプレート

• django/contrib/admin/templates/registration/password_reset_form.html
• django/contrib/admin/templates/registration/password_reset_done.html
• django/contrib/admin/templates/registration/password_reset_confirm.html
• django/contrib/admin/templates/registration/password_reset_complete.html

（メールタイトル・本文のテンプレート）

• django/contrib/auth/templates/registration/password_reset_subject.txt
• django/contrib/admin/templates/registration/password_reset_email.html

宣伝

Django の技術同人誌をこれまでに４冊出しました。開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第１弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文192ページ。最新の Django 3.2 LTS に対応。

★ Amazon（電子版／ペーパーバック）

現場で使える Django の教科書《基礎編》［3.2 LTS 対応版］

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第２弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。

★ Amazon（電子版／ペーパーバック）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」（通称「DRF」）にフォーカスした、「現場で使える Django の教科書」シリーズの第３弾。B5・本文220ページ。

★ Amazon（電子版／ペーパーバック）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django 管理サイトのつくり方

Django の管理サイト（Django Admin）だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。

★ Amazon（電子版）

現場で使える Django 管理サイトのつくり方 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International, Inc.

電子版

★ BOOTH（紙の本）

はじめに

今回のトークに先立って事前に Twitter でアンケートを取ったところ、約73％の方が「DRF を使っている」と回答していたのですが、私の予想を遥かに超えて DRF が使われていることに驚きました（正直半々くらいかなと思っていました…）。

【Django アンケート】
DRF（Django REST Framework）を使っていますか？

（※11月10日の「みんなのPython勉強会#87」で発表予定のトーク『Django REST Framework はじめの一歩（仮）』用のアンケートです。）#Django#stapy

— akiyoko / 現場で使えるDjangoの教科書《基礎編》（3.2対応版）@技術書典11 (@aki_yok) October 25, 2022

ここで、アンケートにご協力いただいた皆さまにこの場を借りて感謝申し上げたいと思います。ご協力ありがとうございました。

また、「Django Developers Community Survey 2021」という7000名を超える開発者アンケートでは、「好きな Django パッケージは何ですか？（複数回答ありで5つまで回答可）」という質問に対して、DRF が第1位に選出されていました。2位の「django-celery」と比較してもダブルスコアというぶっちぎりの結果になっていますね。

DRF とは？

本題に入る前にまず、DRF とは何か？を説明したいと思います。一言でいえば、DRF は「REST API を作成する際の多彩なニーズに応えるための超ド定番 Django パッケージ」です。 Django 単体では不足しているさまざまな機能を、DRF で補完してくれているというイメージになります。特に、Django 開発者なら理解しやすい作りになっているというのが、Django 開発者にとってうれしい特徴です。

続いて、REST API の概要についても説明します。
REST API はスマホや SPA のバックエンドとして よく利用されています（左図）。そして、REST API は、URI でリソースを特定し、HTTP メソッドでそのリソースへの操作を表すという直感的に理解しやすいシンプルな設計になっています（右図）。そんな共通の枠組みに則ったデータを介すことで、フロントエンドとバックエンドが疎結合化、すなわち、お互いのプログラミング言語やアーキテクチャを意識することなくデータをやり取りすることができるのです。なお、REST API はリソース中心の設計となっているので、モデル中心の Django と親和性が高いというのも DRF を使うメリットになるかと思います。

DRF が一番得意なのは、単一リソースの CRUD を処理する REST APIです。上の表に示したように、単一リソースの CRUD を処理する REST API は、「GET」「POST」「PUT」「PATCH」「DELETE」という HTTPメソッドそれぞれに意味を持たせ、リソースを表す URI と組み合わせて、「リソース一覧の取得」「リソース詳細の取得」「リソースの登録」「リソースの更新」「リソースの一部更新」「リソースの削除」といった API を構成します。これを DRF で実装するのはすごく簡単で、モデル除けば最短20行くらいで書くことができます（コード例については後ほど紹介します）。

ここで、DRF についてよくある「誤解」を紹介します。
よくある誤解その①「DRF では単一リソースを扱う API 以外は作れない」は「✕」です。先に説明した 単一リソースを扱う REST API 以外にも、上の表に示したような、リソースがネストした API、独自アクションを追加した API、リソースに紐付いていない API なども DRF で作成することができます。

よくある誤解その②「DRF なしでは JSON のやり取りができない」も「✕」です。Django 単体でも（やろうと思えば）JSON データを受け取って JSON データを返すことができます。下の例を見てください。

api/views.py

import json
from django.forms.models import model_to_dict
from django.http.response import JsonResponse
from django.views import View
from shop.models import Book


classBookCreateView(View):
    """本モデルの登録APIクラス"""defpost(self, request, *args, **kwargs):
        """本モデルの登録APIに対応するハンドラメソッド"""
        data = json.loads(request.body)
        # バリデーションを実行ifnot data.get('title'):
            return JsonResponse({'message': 'タイトルは必須です。'}, status=400)
        # モデルオブジェクトを登録
        book = Book(**data)
        book.save()
        # レスポンスオブジェクトを作成して返すreturn JsonResponse(model_to_dict(book), status=201)

入力パラメータとなる JSON データは request.body に入っているのでそれをパースして、（この例ではめちゃくちゃ適当ですが）バリデーションを適宜実行して、モデルオブジェクトにデータを詰め替えて永続化して、最後に JsonResponse オブジェクトを作成して返しています。でもこんなことを毎回するのは大変ですよね。できれば Django っぽい書き方で、こういった処理を共通化したいというニーズから DRF が誕生したんじゃないかなと思います。

次は、DRF を使うメリットについて。
まず、Django のノウハウやエコシステムが活用できるというのが、DRF を使う大きなメリットになります。むしろこれがほとんどすべてと言っても過言ではありません。DRF プロジェクトのベースはあくまでも Django なので、ORM やマイグレーションを始めとする多くの機能をフル活用できたり、いつも使っている Django パッケージが使えたりといったように、Django のノウハウやエコシステムをほぼそのまま使うことができます。

そして次に、人気があって枯れていることもメリットです。DRF は Django で REST API を作るとなった場合にほぼ一択になるほど人気で、特に英語圏での情報がたくさんあります。公式ドキュメントやチュートリアルも（英語になりますが）かなり充実しています。

機能が充実していることも DRF ならではのメリットです。例えば、Cookie認証、トークン認証、JWT認証などの API でよく利用される認証を簡単に利用することができます。また、アクセス権制御をするための「パーミッション」機能、クエリ文字列による検索をするための「フィルタリング」機能、「ページネーション」機能、APIの利用回数制限をするための「スロットリング」機能などが用意されており、それぞれが差し替えできるようになっています。さらに、画面で API を実行確認できる「Browsable API」と呼ばれるテストクライアントがすぐに使えたり、OpenAPI に準拠した API ドキュメントを出力したりすることもできます。こういった REST API を作成するのに必要な機能がたいてい揃っていて、簡単な設定をするだけで幅広いニーズを満たすことができるというのが大きな特徴になります。

逆に、DRF にはどんなデメリットがあるのでしょうか。

ズバリ… 複雑です。

Django だけでも十分複雑なのに、そこに DRF が加わったらさらに複雑になってしまいますよね。

そこでここからは、DRF 初心者が押さえておきたい次の3つのポイントを解説していきたいと思います。

• ポイント①：全体像を把握しよう
• ポイント②：シリアライザはフォームっぽく使える
• ポイント③：起点は DRF 用ビュー

この3つについてそれぞれ詳しく説明していきます。

ポイント①：全体像を把握しよう

ポイント①「全体像を把握しよう」について。

まず比較のために、Django プロジェクトの全体像と登場人物について説明します。図の左側から来たリクエストを、URLディスパッチャと呼ばれる Django のコアコンポーネントがハンドリングし、URLconf で登録したビュー関数を呼び出して、ビューの中でフォームやモデル、テンプレートを使って、レスポンスを作成して返し、URLディスパッチャがレスポンスを処理するという流れになっています。ミドルウェアは、ビューが呼び出される前や後で何らかの処理をするために利用されます。

REST API を構築するための DRF プロジェクトでは、（HTML のフォーム要素を扱わないし、レスポンスとして画面をレンダリングした HTML を返さないので）基本的にフォームとテンプレートは使いません（後述しますが、Django を共存させる場合にはその限りではありません）。その代わり、DRF では「シリアライザ」というコンポーネントを使います。シリアライザは入出力の JSON（およびモデルとの連携）定義とバリデーションを担当します。ポイント②で詳しく説明しますが、シリアライザはフォームに似せて作られていて、フォームと同じように使うことができます。

そしてビューは、DRF用のビューを使います。これもポイント③で説明しますが、図を見ると分かるように、DRF の起点となるのは「DRF 用ビュー」です。図では「✕」で示していますが、通常の Django のビューを URLconf に登録しておくことも可能です。

それ以外のモデル、URLconf、ミドルウェアは通常の Django と同じように使います。

ポイント①のまとめです。DRF では、DRF用のビュー を作成して URLconf に登録します。そしてシリアライザというコンポーネントを使い、フォームとテンプレートは使いません。ただし、Django と DRF のビューをそれぞれ登録することができるので、そういった共存をさせる場合にはフォームもテンプレートも使うことになるので誤解のないようにしてください。それ以外は通常の Django とだいたい同じように使います。こういった全体像を押さえておくのが第一のポイントです。

ポイント②：シリアライザはフォームっぽく使える

ポイントその②「シリアライザはフォームっぽく使える」について。

その前にまず、DRF の独自コンポーネントである「シリアライザ」の使いどころを説明します。シリアライザが担当する役目は、

• 入力データのバリデーション
• モデルオブジェクトの永続化
• 出力データの作成

です。上の図はどこでシリアライザを使うかを示しているのですが、登録API、更新API、取得API のそれぞれでシリアライザの使いどころが異なります（削除API のようにシリアライザを使わない場合もあります）。例えば登録 API だと、リクエストされた JSON データを元にしてシリアライザオブジェクトを作成し、シリアライザオブジェクトのバリデーションメソッドを実行し、シリアライザの永続化メソッドを実行して、最後にレスポンスオブジェクトの引数にシリアライザのデータを渡すという流れになります。このように、ほとんどの場合でシリアライザを使うことになるため、DRF を使うときにはシリアライザは避けて通ることができません。

さて、本題です。シリアライザはフォームっぽく使えるということについて説明します。リソース（すなわちモデル）と紐付いた REST API の場合は「ModelSerializer」を使うのが基本なのですが、ModelSerializer の使い方は（フォームで特定のモデルを扱うための）ModelForm とほぼ同じです。 ModelSerializer と ModelForm の引数や属性、バリデーション、永続化の流れを上の図に並べて示したのですが、仕組みがほぼ同じになっています。バリデーションメソッドは「is_valid」、永続化メソッドは「save」でこちらも同じです。ただし、バリデーション済みのデータは「validated_data」となっていて、ModelForm（親クラスの Form も同様）と変数名が異なるので注意してください。

シリアライザの実装イメージは次のようになります。

api/serializers.py

from rest_framework import serializers

from shop.models import Book


classBookSerializer(serializers.ModelSerializer):
    """本モデル用シリアライザ"""classMeta:
        model = Book
        fields = ['id', 'title', 'price']

ModelSerializer を継承したシリアライザクラスを用意して、Metaクラスの「model」属性に連携させるモデルクラス、「fields」属性に JSONの入出力フィールドとして利用するモデルのフィールド名を指定します。フィールドは、fields 属性以外に、除外するフィールドを excludes 属性で指定することもできます。

使い方は ModelFormとほぼ同じで、引数「data」にリクエストのパラメータ（DRF では JSON データ）、更新時には引数「instance」にモデルオブジェクトを指定します。バリデーションをおこなたいときは is_valid()、モデルオブジェクトを永続化したいときは save() メソッドを実行します。

>>> from api.serializers import BookSerializer
>>> serializer = BookSerializer(data={'title': 'DRFの本', 'price': 1000})
>>> serializer.is_valid()
True
>>> serializer.validated_data
OrderedDict([('title', 'DRFの本'), ('price', 1000)])
>>> book = serializer.save()

>>> serializer = BookSerializer(instance=book, data={'price': 2000}, partial=True)
>>> serializer.is_valid()
True
>>> serializer.save()
<Book: DRFの本>

ポイント②のまとめです。モデルと紐付いた REST API の場合は ModelSerializer を使うのが簡単で、その使い方は ModelForm とほぼ同じです。

ポイント③：起点は DRF 用ビュー

最後のポイント「起点は DRF 用ビュー」について。

DRF には「rest_framework.views.APIView」というクラスが用意されているのですが、「APIView」は DRF の起点となる基底ビュークラスで、これを継承することで、さまざまな前処理と後処理をやってくれます。

1. リクエストオブジェクトを DRF 用に変換
2. レンダラクラスとメディアタイプを決定
3. バージョニング
4. 認証チェック
5. パーミッションチェック
6. スロットリング
7. 例外ハンドリング

これらの処理は差し替え可能です。2. 〜 6. には代表的な処理クラスがいくつか用意されていて、デフォルトの設定を設定ファイル（settings.py）の「REST_FRAMEWORK」で上書きして全体的な設定をしたり、クラス変数をオーバーライドしてビュークラス単位での個別設定をしたりすることができます。

DRF 用のビューは大きく分けて3種類あり、用途に応じて

1）rest_framework.views.APIView
2）rest_framework.generics.CreateAPIView などの 汎用 APIView
3）rest_framework.viewsets.ModelViewSet 系ビュー

のいずれかを継承して作成します。どれを選択するかによってそれぞれカスタム性やコード量が異なってきますが、この後で具体的な実装を見ながら説明していきます（コードがたくさん出てきますが、雰囲気を理解してもらえれば大丈夫です）。

ちなみに下の図で示すように、2) と 3) のビューは「APIView」の子クラスで、APIView は「基本汎用ビュー」と呼ばれる Django の「View」クラスの子クラスです。

まず、1）の APIView を継承したビューの書き方について説明します。

例えば、更新 API で呼び出される post メソッドでは、モデルオブジェクトと入力データからシリアライザオブジェクトを作成し、is_valid() で入力データのバリデーションをおこない、save() でモデルオブジェクトを更新して、最後にシリアライザの data 属性の値を使ってレスポンスオブジェクトを作成して返しています。

api/views.py

from rest_framework import status, views
from rest_framework.generics import get_object_or_404
from rest_framework.response import Response

from shop.models import Book
from .serializers import BookSerializer


classBookRetrieveUpdateAPIView(views.APIView):
    """本モデルの取得（詳細）・更新APIクラス"""defget(self, request, pk, *args, **kwargs):
        """本モデルの取得（詳細）APIに対応するハンドラメソッド"""# モデルオブジェクトを取得
        book = get_object_or_404(Book, pk=pk)
        # シリアライザオブジェクトを作成
        serializer = BookSerializer(instance=book)
        return Response(serializer.data, status.HTTP_200_OK)

    defput(self, request, pk, *args, **kwargs):
        """本モデルの更新APIに対応するハンドラメソッド"""# モデルオブジェクトを取得
        book = get_object_or_404(Book, pk=pk)
        # シリアライザオブジェクトを作成
        serializer = BookSerializer(instance=book, data=request.data)
        # バリデーションを実行
        serializer.is_valid(raise_exception=True)
        # モデルオブジェクトを更新
        serializer.save()
        # レスポンスオブジェクトを作成して返すreturn Response(serializer.data, status.HTTP_200_OK)

コードは長くなりますが、好きなように書くことができます。しかし、単一リソースの CRUD 処理をする場合、モデルとシリアライザだけが違うビューを追加する場合に同じようなコードを何度も書くのはさすがに冗長ですよね。

そんな場合に利用したいのが、2）の「汎用 APIView」です。上の表に示したように、対応アクションごとにいろいろな汎用 APIView が用意されているので、用途に合わせてどれかを継承して、モデルオブジェクトを取得するためのクエリを指定するための「queryset」とシリアライザクラスを指定するための「serializer_class」をクラス変数を加えるだけです。

これでだいぶ短く書くことができますが、単一モデルのCRUD処理をするというのを逸脱した API を作ろうとすると、親クラスのメソッドをオーバーライドして拡張する必要があります。

api/views.py

from rest_framework import generics

from shop.models import Book
from .serializers import BookSerializer


classBookListCreateAPIView(generics.ListCreateAPIView):
    """本モデルの取得（一覧）・登録APIクラス"""

    queryset = Book.objects.all()
    serializer_class = BookSerializer


classBookRetrieveUpdateDestroyAPIView(generics.RetrieveUpdateDestroyAPIView):
    """本モデルの取得（詳細）・更新・一部更新・削除APIクラス"""

    queryset = Book.objects.all()
    serializer_class = BookSerializer

config/urls.py

from django.urls import path
from api import views

urlpatterns = [
    path('api/books/', views.BookListCreateAPIView.as_view()),
    path('api/books/<pk>/', views.BookRetrieveUpdateDestroyAPIView.as_view()),
]

最後に、3）ModelViewSet 系ビューを継承したビューの書き方です。冒頭で「単一リソースの CRUD を処理する REST API なら超簡単」で「20行くらいで API が全部書ける」と言っていたのはこちらです。

上の表に書いたように ModelViewSet は「一覧」「詳細」「登録」「更新」「一部更新」「削除」という6つの API を全部網羅しています。実装は、下に示したように ModelViewSet を継承して、「serializer_class」と「queryset」の指定をするだけです。

api/views.py

from rest_framework import viewsets

from shop.models import Book
from .serializers import BookSerializer


classBookViewSet(viewsets.ModelViewSet):
    """本モデルのCRUD用APIクラス"""

    serializer_class = BookSerializer
    queryset = Book.objects.all()

あとは、ViewSet 用の SimpleRouter（または DefaultRouter）を利用して URL パターンを URLconf に追加してあげれば、これで API の実装は完了です。シリアライザを含めて最短20行ほどで書くことができます。

config/urls.py

from django.urls import include, path
from rest_framework import routers
from api import views

router = routers.DefaultRouter()
router.register('books', api.BookViewSet)

urlpatterns = [
    # すべてのアクション（一覧・詳細・登録・更新・一部更新・削除）をまとめて追加
    path('api/', include(router.urls)),
]

なので、単一モデルの CRUD を処理する REST API をまるっと実装したいというニーズには「ModelViewSet」が一番最速で実装できるということになります。

ポイント③のまとめです。単一モデルの CRUD を処理する REST API をまるっと実装したい場合は ModelViewSet 系ビューを使うのが一番簡単で、複雑なことがしたい場合は APIView（または GenericAPIView）を継承したビュークラスを使うのがよいでしょう。

まとめ

最後のまとめです。

DRFを使う場合、Django に DRF の要素、コンポーネントが加わることになるので複雑になります。なのでまずは、全体像を把握しましょう。一見複雑にみえますが、新しい要素は「シリアライザ」と「DRF用ビュー」です。

「シリアライザ」は入力データのバリデーション、内部に保持したモデルオブジェクトの永続化、出力データの作成を担当するクラスで、Django のフォームと同じような使い方ができます。

「DRF用ビュー」は大きく3種類あり、まるっと API 全部を実装できてしまうものもあれば、複雑なカスタム API にも対応できるものもあるので、用途に合わせて親クラスと書き方を使い分けてください。

さてこれで、DRF がどんなものか完全に理解できたでしょうか。もっと DRF のことを深く知りたいという方は、「現場で使える Django REST Framework の教科書」という 220ページ以上まるまる DRF について書かれた素敵な本があるので、そちらを読んでみてください。ここで説明した内容をもっとディープに解説しています。そして何と、今月この本が改訂予定です。Django 3.2 LTS、DRF 3.14 対応で、Vue 3（+ Vite）と Vuetify 3 でチュートリアルを刷新しています。

トークのスライドはこちらにアップしています。

speakerdeck.com

宣伝

Django の技術同人誌をこれまでに４冊出しました。開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第１弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文192ページ。最新の Django 3.2 LTS に対応。

★ Amazon（電子版／ペーパーバック）

現場で使える Django の教科書《基礎編》［3.2 LTS 対応版］

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第２弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。

★ Amazon（電子版／ペーパーバック）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」（通称「DRF」）にフォーカスした、「現場で使える Django の教科書」シリーズの第３弾。B5・本文220ページ。

★ Amazon（電子版／ペーパーバック）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django 管理サイトのつくり方

Django の管理サイト（Django Admin）だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。

★ Amazon（電子版）

現場で使える Django 管理サイトのつくり方 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International, Inc.

電子版

★ BOOTH（紙の本）

課題

まず大前提ですが、Django モデルの仕様として、それぞれのモデルごとに単一の主キーを持たせる必要があり（「primary=True」オプションを持つフィールドをモデルに明示的に含めるか、さもなくば「id」という名前のフィールドが自動的にモデルに追加され、それに対応したカラムがテーブルに作成される）、複合主キー（composite primary key）はサポートされていません。*1

そのため、例えば、単一の主キーを持たない（が複合主キーを持っている）既存のテーブルを Django モデルで扱うことは困難です。

ところで Django で複合主キーっぽいことをしたければ通常は、「id」という名前のサロゲートキーを主キーとして別に用意しつつ、複合ユニーク制約を利用しますよね。具体的には、Django 2.2 から追加された UniqueConstraintを利用して次のように実装します。

models.py

from django.db import models


classEmployee(models.Model):
    """従業員モデル"""classMeta:
        db_table = 'employee'
        verbose_name = verbose_name_plural = '従業員'
        constraints = [
            models.UniqueConstraint(fields=['branch_code', 'employee_code'], name='unique_employee')
        ]

    branch_code = models.CharField('支店コード', max_length=3)
    employee_code = models.CharField('従業員コード', max_length=5)
    name = models.CharField('従業員名', max_length=255)

    def__str__(self):
        return f'{self.branch_code}-{self.employee_code}'

この従業員テーブルの仕様としては、支店ごとに従業員コードが振られていて、従業員コードはレコード全体としてはユニークになっていない（支店コードと従業員コードを合わせるとユニークになる）という想定です。

ちなみに複合ユニーク制約を実現するには unique_togetherを使うことも可能ですが、将来的に非推奨になる可能性があり、UniqueConstraint の方が多機能なので、UniqueConstraint の利用が推奨されます。

解決策

最近見つけたのですが、（次期リリースではありますが）「Viewflow」というライブラリの「CompositeKey」を使えば、既存テーブルに主キーがないテーブルを Django モデルで扱うことが可能になります。

使い方は次の通りです。

pip install django-viewflow --pre

# or

pip install django-viewflow==2.0.0a2

models.py

from django.db import models
from viewflow.fields import CompositeKey


classEmployee(models.Model):
    """従業員モデル"""classMeta:
        db_table = 'employee'
        managed = False
        verbose_name = verbose_name_plural = '従業員'id = CompositeKey(columns=['branch_code', 'employee_code'])
    branch_code = models.CharField('支店コード', max_length=3)
    employee_code = models.CharField('従業員コード', max_length=5)
    name = models.CharField('従業員名', max_length=255)

    def__str__(self):
        return f'{self.branch_code}-{self.employee_code}'

これで、CompositeKey の columns で指定した複数のフィールドの値を「{'branch_code': '001', 'employee_code': '00001'}」のような JSON 文字列で保持する「id」という名前の 仮想フィールドを持つことができます。

「managed = False」*2を指定しないとマイグレーションで「id」カラムが作成されてしまうのですが、CompositeKey が威力を発揮するのは「managed = False」を指定してモデルをマイグレーションの対象外にした場合で、主キーを持たない既存のテーブルに影響を及ぼさずに Django モデルを用意することができます。事例としては、次のように複合主キーを持った既存テーブルから Django ORM を使ってレコードを抽出（読み取り専用）したいというニーズに応えることができます。

Django 管理サイトでも動作するというのも高評価です。

Q1．回答者の Django 経験年数

Q1．Django の経験はどのくらいですか？

• 経験なし
• 1年未満
• 1〜3年くらい
• 3〜5年くらい
• 5年以上

回答者の Django 経験年数の分布は次のようになりました。

一番多かったグループは「1〜3年くらい」で 40％でした。なお、「1年未満」の階級値を「0.5」、「1〜3年くらい」を「2」、「3〜5年くらい」を「4」、「5年以上」を「7.5」として計算した 回答者の Django 経験年数の平均は 3.8 年でした。

Q2．Django パッケージ利用状況

代表的な Django パッケージ 35個について、それぞれの利用状況を「聞いたことがない」「聞いたことはあるが使ったことはない」「試しに使ったことがある」「現場で使っている（過去に使っていた）」の４択でアンケートしました。

パッケージの選定にあたっては、毎年数千名が参加する Django 開発者向けアンケート「2022 Django Developers Survey」の「お気に入りのサードパーティ Django パッケージは？」という質問の選択肢をそのまま利用しました。*1

Q2．次の Django パッケージをそれぞれどのくらい利用していますか？

• 1: 聞いたことがない
• 2: 聞いたことはあるが実際に使ったことはない
• 3: 試しに使ったことがある
• 4: 現場で使っている（過去に使っていた）

Django パッケージの選択肢

• dj-database-url
• dj-rest-knox
• dj-rest-auth
• django-allauth
• django-braces
• django-celery
• django-celery-beat
• django-channels
• django-click
• django-compressor
• django-configurations
• django-cors-headers
• django-crispyforms
• django-dbbackup
• django-debug-toolbar
• django-environ
• django-extensions
• django-filter
• django-import-export
• django-lifecycle
• django-model-utils
• django-money
• django-redis
• django-rest-swagger
• django-storages
• django-silk
• django-taggit
• django-test-plus
• djangorestframework
• djangorestframework-simplejwt
• Djoser
• model-bakery
• pylint-django
• pytest-django
• Wagtail

回答結果を 4 > 3 > 2 > 1 の優先順に並べ替えた利用度ランキングがこちらになります。

３人に２人が現場で使っているという「djangorestframework」（DRF）がダントツの１位でした。「試しに使ったことがある」を足し合わせると95％というのも衝撃の結果ですよね。「django-cors-headers」の利用度も高いことから、現場で DRF を使って API 開発をしている方が多いことが伺えます。

次点の 「django-debug-toolbar」は２人に１人くらいが現場で使っているという結果になりました。私は開発時にはどのプロジェクトにも「django-debug-toolbar」と「django-extensions」はとりあえず入れるようにしていますが、そんな感じで「とりあえず生！🍺」みたいに使われているのかもしれません。*2

「4: 現場で使っている」「3: 試しに使ったことがある」「2: 聞いたことはある」を足し合わせたものを「認知度」とすると、認知度が高いほど、現場で使っている割合が全体的に高い傾向にありますが、認知度の割には現場で利用されていない（現場で使っていない割には認知度が高いとも解釈できる？）パッケージとして「django-allauth」「django-crispyforms」「django-channels」などが挙げられるでしょうか。

なお、「django-celery」は開発が長年停滞していて現時点で公式サポートされているバージョンの Django には対応していないようなのですが、今回のアンケートでは過去に現場で使っていたということで票が入ったのでしょう。*3

経験年数による変化

ここで Q1. とQ2. の結果を組み合わせて、少し考察をしてみたいと思います。

まず、経験年数のグループごとに「現場で使っている」と回答したパッケージ数の平均を比較してみます。

3〜5年くらいを境にして、利用しているパッケージの数が跳ね上がっているように見えます。だいたい3年目くらいから複数の現場を経験するようになるということなのかもしれませんね。

次に、「Django 経験が長い人ほど利用度が高くなるパッケージはどれか？」を調べるために、経験年数とパッケージ利用度の相関を計算してみました。相関が高い Django パッケージランキングの上位５つを下に示します。

これらはベテランならではのニーズに答えてくれるパッケージということなのでしょうか。まだこれらのパッケージを試したことがないという方は、ぜひチェックしてみてください。

PyPI ダウンロード数のランキングとの比較

「The 10 Most-Used Django Packages | LearnDjango.com」という記事にインスパイアされ、PyPI のダウンロード数を元にした別角度での利用度ランキングを作成してみました。PyPI のダウンロード数は「Top PyPI Packages」というサービスから取得しました。

パッケージ名の右側のカッコ内の数字は先に示した「現場で使っている」ランキングの順位ですが、多少のブレはあるものの今回の結果と比較して違和感のない結果になっている印象です。

直近のダウンロード数を元にしていることで、プロジェクトがすでにアーカイブ済みになっている「django-rest-swagger」のダウンロード数が少なかったり、開発が長年停滞している「django-celery」などのパッケージがランキング外になっていたりするのは、まさに現時点での「利用実態」を表していると言えるでしょう。

GitHub スター数のランキングとの比較

次に、12/14 時点の GitHub スター数で並べた人気ランキングを見てみます。

同じく、カッコ内の数字は先に示した「現場で使っている」ランキングの順位ですが、（PyPI のダウンロード数ランキングと比べて）少し乖離が大きいような感じがします。

例えば、上位にランクインしている「Wagtail」は８年以上、「django-allauth」は12年以上も継続しているリポジトリということでスター数が多くなっている可能性がありますし、「django-channels」は Django の公式コミュニティが開発しているということで注目度が高いためにスター数が多くなっている可能性があります。また、現在のスター数は多いけれども実際はもう使われなくなってしまったリポジトリもあったりするので、実際の利用実態と乖離していることもあるでしょう。

ということで、パッケージを選定する際には、GitHub スター数を「人気度」として参考にしつつ、PyPI の直近のダウンロード数を「利用度」として判断材料にするのがよいのではないでしょうか。なお、実際の選定にあたっては次の点も留意するのがよいでしょう。

• 開発が停滞していないか（直近の PyPI ダウンロード数である程度把握できる）
• Issue が放置されていないか
• 公式ドキュメントが充実していること
• コントリビュータが数人以上いること（ぼっち開発は危険）

まとめ

独自のアンケートを採って、「実際の現場ではどんな Django パッケージがどれくらい使われているのか？」を調査しました。

「Q2．Django パッケージ利用状況」の結果のグラフを見ると、特異的に認知度が高いものがいくつかあったものの、全体的に、認知度が高いほど現場で利用されている度合いが高い傾向にあることが分かりました。結果としては、「djangorestframework」が認知度・利用度ともダントツのトップでした。

今回は、私が全然知らなかった Django パッケージも含めてアンケートをすることができたので、大変興味深く調査することができました。アンケートにご協力いただいた皆さま、誠にありがとうございました。改めて御礼申し上げます。

参考までに、アンケート結果の可視化に利用したコードは ↓ にアップしています。

github.com

（おまけ）ChatGPT による Django パッケージの説明

今回のアンケートの選択肢として挙げたそれぞれの Django パッケージの説明文を載せておきます。ちなみにこの説明文は、最近話題の「ChatGPT」の回答を使わせていただきました。ざっとチェックしましたが、しれっと大嘘をついている可能性があるかもしれませんのでご注意ください。

宣伝

Django の技術同人誌をこれまでに４冊出しました。開発のお供にどうぞ。

現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第１弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文192ページ。最新の Django 3.2 LTS に対応。

★ Amazon（電子版／ペーパーバック）

現場で使える Django の教科書《基礎編》［3.2 LTS 対応版］

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第２弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。

★ Amazon（電子版／ペーパーバック）

現場で使える Django の教科書《実践編》

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」（通称「DRF」）にフォーカスした、「現場で使える Django の教科書」シリーズの第３弾。B5・本文220ページ。

★ Amazon（電子版／ペーパーバック）

現場で使える Django REST Framework の教科書 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International,Inc.

電子版

ペーパーバック

★ BOOTH（紙の本）

現場で使える Django 管理サイトのつくり方

Django の管理サイト（Django Admin）だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。

★ Amazon（電子版）

現場で使える Django 管理サイトのつくり方 (Django の教科書シリーズ)

横瀬 明仁 ／ Amazon Services International, Inc.

電子版

★ BOOTH（紙の本）