Userモデル関係を整理してみる まとめ
USERモデル関係 他の記事
本題
そもそもUserモデルとは
djangoを勉強していて急に出てくるUserという言葉。ドキュメント内でそれらが当たり前のように様々な説明に絡む。もやもやした。
勉強してきて少しずつ分かってきたことを記載する。
まずdjangoをpython manage.py makemigrations, python manage.py migrateしたときにUserモデルが作られる。Userモデルという表現は馴染みにくいけど、データベースやテーブルと考えるとよい。Userモデルはユーザーのデータベースであって、こちらにユーザ情報を追加したり、削除して管理する。わけもわからずpython manage.py createsuperuser とかコードを叩いた経験があるけど、その結果Userというところにスーパーユーザーの情報が登録されているのを確認できる。テーブルのカラムにあたるものを記入されることを要求されたり、adminにスーパユーザとしてデータ登録されている事実を踏まえるとデータベースだと認識できると思う。勉強開始当初この認識を妨げ、ユーザモデルをもやもやにする理由は以下にあると思う。
普通はmodels.pyに自分で作りたいデータベース（テーブル）の枠組みを記述し、makemigrations,migrateを経てデータベースを作成する。Userモデルだけはこの一連の処理をしない。自分ではデータベースを作っていない認識になってしまう。
ユーザモデルだけは予め作ってくれるものだ、と認識すると初学者にとって理解の助けになる。
カスタムUserモデル
これは上記のスタートプロジェクトしたときに作られるUserモデルと対立するモデルと考えれば良い。予め作ってくれるUserモデルではなく、自前で（models.pyでクラスを規定、makemigrations,migrate）作ったモデル。カスタムと呼ばれる所以は自動的に作られるUserモデルでは役割不足なので自分のプロジェクトにあったUserモデルを作るところにある。プロジェクト途中でユーザモデルを変更するのは大変らしい。
そこでドキュメントではプロジェクト開始時にカスタムUserモデルを作成しとくこととアドバイスしている。このときにAUTH_USER_MODELもmakemigrations migrate前に設定すること。
プロジェクトの開始時にカスタムのユーザーモデルを使用する
AUTH_USER_MODEL
これも何が何だか分からない、何のために存在しているか分からない印象だった。
これは上記２つのモデルが存在することで必要になるものだ。自前のカスタムUserモデルを作った場合、既存のUserモデルもあるのでユーザーモデル一つのプロジェクトで併存してしまう。どっちのモデルを使いますという宣言がAUTH_USER_MODELです。
使い方一例：AUTH_USER_MODEL=Myapp.MyUser
get_user_model()
これも一体何のために存在するかわからなかった。ドキュメントには以下のように書いてあるけどこれを使う場面と結びつかないから自分は困った。
"""User を直接参照する代わりに、django.contrib.auth.get_user_model() を使ってユーザモデルを参照すべきです。このメソッドは現在アクティブなユーザモデルを返します -- 指定されている場合はカスタムのユーザモデル、指定されていない場合は User です。"""
https://docs.djangoproject.com/ja/2.1/topics/auth/customizing/#referencing-the-user-model
自分はget_user_model()をUserモデルデータベースを編集するときに使うイメージにした。
User=get_user_model()とすると、今使われているUserモデルを返してくれるので以下のようにできる。
User.objects.create_user(**********) みたいな使い方をする
