Il a été bloqué pendant environ 10 minutes.
Même si vous recherchez sur Google, vous ne trouvez pas de solution et peut-être avez-vous un problème similaire.
J'utilise Django et PostgreSQL.
J'ai utilisé la table auth_user créée par défaut dans Django, mais j'ai créé une nouvelle table QiitaUser qui étend la table auth_user, et maintenant j'utilise QiitaUser (le nom de la table est provisoire).
以前のmodels.py
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)
変更後のmodels.py
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)
settings.py
AUTH_USER_MODEL = 'QiitaUser'
Modifiez models et settings.py comme ci-dessus et exécutez la migration pour confirmer que la table qiitauser est créée.
La table Engineer, qui faisait à l'origine référence à l'id_utilisateur de auth_user, fait désormais référence à l'id de la table qiitauser en tant que clé externe (elle a été reconnue).
Lorsque j'essaye d'enregistrer les données d'ingénieur en spécifiant l'id de 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".
Si vous spécifiez un identifiant qui existe dans la table QiitaUser comme user_id de l'ingénieur, une erreur se produira s'il n'y a pas d'enregistrement pour cet identifiant dans la table auth_user.
Je veux que vous vous référiez à l'id de QiitaUser, mais j'ai fait référence à l'id de auth_user.
Dans mon environnement de développement, avec la contrainte de clé externe sur auth_user déjà attachée, j'ai défini une nouvelle table étendue de auth_user et fait référence à AUTH_USER_MODEL = QiitaUser, donc la contrainte de clé externe est auth_user et QiitaUser. Il semble que les deux étaient attachés et une erreur s'est produite lors de la tentative de référence à 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
Dans PostgreSQL, vous pouvez vérifier la définition de la table avec \ d <tablename>;.
La contrainte de clé externe qui fait référence à l'ID de auth_user n'est plus nécessaire et doit être supprimée.
db=# ALTER TABLE engineer DROP CONSTRAINT IF EXISTS engineer_user_id_xxxxxxxx_fk_auth_user_id;
ALTER TABLE
Lorsque j'essaye à nouveau d'enregistrer les données de l'ingénieur ...
db=# update engineer set user_id = 10 where id = 15;
UPDATE 1
C'était un succès.
Si vous n'avez pas défini un ingénieur qui fait référence à auth_user et que vous le migrez, mais que vous utilisez un modèle qui étend auth_user au moment de la migration pour la première fois après la création d'un ingénieur, je pense que le problème comme celui-ci ne s'est pas produit.
Soyez prudent lors de la définition et de l'utilisation d'un nouvel utilisateur personnalisé alors que vous utilisez déjà auth_user.
Recommended Posts