Fixed #24370 -- Recommended starting with a custom user model.
This commit is contained in:
parent
e044026dce
commit
d02a03d574
|
@ -395,42 +395,55 @@ This dotted pair describes the name of the Django app (which must be in your
|
||||||
:setting:`INSTALLED_APPS`), and the name of the Django model that you wish to
|
:setting:`INSTALLED_APPS`), and the name of the Django model that you wish to
|
||||||
use as your User model.
|
use as your User model.
|
||||||
|
|
||||||
.. warning::
|
Using a custom user model when starting a project
|
||||||
|
-------------------------------------------------
|
||||||
|
|
||||||
Changing :setting:`AUTH_USER_MODEL` has a big effect on your database
|
If you're starting a new project, it's highly recommended to set up a custom
|
||||||
structure. It changes the tables that are available, and it will affect the
|
user model, even if the default :class:`~django.contrib.auth.models.User` model
|
||||||
construction of foreign keys and many-to-many relationships. If you intend
|
is sufficient for you. This model behaves identically to the default user
|
||||||
to set :setting:`AUTH_USER_MODEL`, you should set it before creating
|
model, but you'll be able to customize it in the future if the need arises::
|
||||||
any migrations or running ``manage.py migrate`` for the first time.
|
|
||||||
|
|
||||||
Changing this setting after you have tables created is not supported
|
from django.conf.auth.models import AbstractUser
|
||||||
by :djadmin:`makemigrations` and will result in you having to manually
|
|
||||||
fix your schema, port your data from the old user table, and possibly
|
|
||||||
manually reapply some migrations.
|
|
||||||
|
|
||||||
.. warning::
|
class User(AbstractUser):
|
||||||
|
pass
|
||||||
|
|
||||||
Due to limitations of Django's dynamic dependency feature for swappable
|
Don't forget to point :setting:`AUTH_USER_MODEL` to it. Do this before creating
|
||||||
models, you must ensure that the model referenced by :setting:`AUTH_USER_MODEL`
|
any migrations or running ``manage.py migrate`` for the first time.
|
||||||
is created in the first migration of its app (usually called ``0001_initial``);
|
|
||||||
otherwise, you will have dependency issues.
|
|
||||||
|
|
||||||
In addition, you may run into a CircularDependencyError when running your
|
Changing to a custom user model mid-project
|
||||||
migrations as Django won't be able to automatically break the dependency
|
-------------------------------------------
|
||||||
loop due to the dynamic dependency. If you see this error, you should
|
|
||||||
break the loop by moving the models depended on by your User model
|
|
||||||
into a second migration (you can try making two normal models that
|
|
||||||
have a ForeignKey to each other and seeing how ``makemigrations`` resolves that
|
|
||||||
circular dependency if you want to see how it's usually done)
|
|
||||||
|
|
||||||
.. admonition:: Reusable apps and ``AUTH_USER_MODEL``
|
Changing :setting:`AUTH_USER_MODEL` after you've created database tables is
|
||||||
|
significantly more difficult since it affects foreign keys and many-to-many
|
||||||
|
relationships, for example.
|
||||||
|
|
||||||
Reusable apps shouldn't implement a custom user model. A project may use
|
This change can't be done automatically and requires manually fixing your
|
||||||
many apps, and two reusable apps that implemented a custom user model
|
schema, moving your data from the old user table, and possibly manually
|
||||||
couldn't be used together. If you need to store per user information in your
|
reapplying some migrations. See :ticket:`25313` for an outline of the steps.
|
||||||
app, use a :class:`~django.db.models.ForeignKey` or
|
|
||||||
:class:`~django.db.models.OneToOneField` to ``settings.AUTH_USER_MODEL``
|
Due to limitations of Django's dynamic dependency feature for swappable
|
||||||
as described below.
|
models, the model referenced by :setting:`AUTH_USER_MODEL` must be created in
|
||||||
|
the first migration of its app (usually called ``0001_initial``); otherwise,
|
||||||
|
you'll have dependency issues.
|
||||||
|
|
||||||
|
In addition, you may run into a ``CircularDependencyError`` when running your
|
||||||
|
migrations as Django won't be able to automatically break the dependency loop
|
||||||
|
due to the dynamic dependency. If you see this error, you should break the loop
|
||||||
|
by moving the models depended on by your user model into a second migration.
|
||||||
|
(You can try making two normal models that have a ``ForeignKey`` to each other
|
||||||
|
and seeing how ``makemigrations`` resolves that circular dependency if you want
|
||||||
|
to see how it's usually done.)
|
||||||
|
|
||||||
|
Reusable apps and ``AUTH_USER_MODEL``
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
Reusable apps shouldn't implement a custom user model. A project may use many
|
||||||
|
apps, and two reusable apps that implemented a custom user model couldn't be
|
||||||
|
used together. If you need to store per user information in your app, use
|
||||||
|
a :class:`~django.db.models.ForeignKey` or
|
||||||
|
:class:`~django.db.models.OneToOneField` to ``settings.AUTH_USER_MODEL``
|
||||||
|
as described below.
|
||||||
|
|
||||||
Referencing the ``User`` model
|
Referencing the ``User`` model
|
||||||
------------------------------
|
------------------------------
|
||||||
|
|
Loading…
Reference in New Issue