It was jammed for about 10 minutes.
Even if you google, you can't find a solution, and maybe you may have a similar problem.
I'm using Django and PostgreSQL.
I used to use the auth_user table created by default in Django, but I created a new table QiitaUser that extends the auth_user table, and now I use QiitaUser (the table name is tentative).
from django.conf import settings from django.db import models class Engineers(models.Model): name = models.CharField(max_length=1000) user = models.ForeignKey(settings.AUTH_USER_MODEL, to_field='id', on_delete=models.CASCADE, null=True)
from django.conf import settings from django.contrib.auth.models import AbstractUser from django.db import models class Engineer(models.Model): name = models.CharField(max_length=1000) user = models.ForeignKey(settings.AUTH_USER_MODEL, to_field='id', on_delete=models.CASCADE, null=True) class QiitaUser(AbstractUser): is_owner = models.BooleanField(default=False)
AUTH_USER_MODEL = 'QiitaUser'
Modify models and settings.py as above and execute migration to confirm that the qiitauser table is created.
The engineer table, which originally referred to the user_id of auth_user, now references the id of the qiitauser table as a foreign key (it was recognized).
When I try to register Engineer data by specifying the id of QiitaUser ...
db=# update engineer set user_id = 10 where id = 15; ERROR: insert or update on table "engineer" violates foreign key constraint "engineer_user_id_xxxxxxxx_fk_auth_user_id" DETAIL: Key (user_id)=(10) is not present in table "auth_user".
If the id that exists in the QiitaUser table is specified in the user_id of the Engineer, an error will occur if there is no record of that id in the auth_user table.
I want you to refer to the id of QiitaUser, but I have referred to the id of auth_user.
In my development environment, with the foreign key constraint on auth_user already attached, I defined a new extended table of auth_user and referred to AUTH_USER_MODEL = QiitaUser, so the foreign key constraint is auth_user and QiitaUser. It seems that both were attached and an error occurred when trying to refer to auth_user.
db=# \d engineer; Table "public.engineer" Column | Type | Collation | Nullable | Default ------------------------+-------------------------+-----------+----------+--------------------------------------------------- id | integer | | not null | nextval('engineer_id_seq'::regclass) name | character varying(1000) | | not null | user_id | integer | | | Indexes: "engineer_pkey" PRIMARY KEY, btree (id) "engineer_user_id_xxxxxxxx" btree (user_id) Foreign-key constraints: "engineer_user_id_xxxxxxxx_fk_accounts_" FOREIGN KEY (user_id) REFERENCES accounts_visualuser(id) DEFERRABLE INITIALLY DEFERRED "engineer_user_id_xxxxxxxx_fk_auth_user_id" FOREIGN KEY (user_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED
In PostgreSQL, you can check the table definition with
\ d <tablename>;.
The foreign key constraint that references the id of auth_user is no longer needed and should be removed.
db=# ALTER TABLE engineer DROP CONSTRAINT IF EXISTS engineer_user_id_xxxxxxxx_fk_auth_user_id; ALTER TABLE
When I try to register the Engineer data again ...
db=# update engineer set user_id = 10 where id = 15; UPDATE 1
It was a success.
If you do not define an Engineer that refers to auth_user and migrate it, but use a Model that extends auth_user at the timing of migrating for the first time after creating an Engineer, I think that the problem like this did not occur.
You need to be careful when defining and using a new CustomUser while already using auth_user.