La migration de Django échoue

Question

J'ai une application django/postgresql. Chaque fois que j'exécute ma dernière migration, je reçois l'erreur suivante :

ValueError : Trouvé un nombre incorrect (0) de contraintes pour le package(speciality, title)

Je crois que je dois personnaliser la migration, mais quelle modification dois-je apporter ?

C'est la migration :

opérations = [

    migrations.AddField(

        model_name='package',

        name='speciality',

        field=models.ManyToManyField(related_name='specialities', to='speciality.Speciality', blank=True),

    ),

    migrations.AlterField(

        model_name='package',

        name='title',

        field=models.CharField(unique=True, max_length=50),

    ),

    migrations.AlterUniqueTogether(

        name='package',

        unique_together=set([]),

    ),

    migrations.RemoveField(

        model_name='package',

        name='speciality',

    ),

]

Voici la configuration actuelle de ma table pour ce modèle :

sleepyfish=# \d p Tableau "public.package Colonne | Type | Modificateurs
---------------+--------------------------+------------------------------------------------------ id | integer | not null default nextval('package_id_seq'::regclass) created_at | timestamp avec avec fuseau horaire | not null updated_at | timestamp avec fuseau horaire | not null title | caractère variable(50) | not null description | Description : texte, statut, booléen
| not null price | numeric(8,2) | not null speciality_id | integer | Indexes : "package_pkey" PRIMARY KEY, btree (id) "package_speciality_id_3aeb5c97679442e4_uniq" CONSTRAINT UNIQUE, btree (speciality_id, title) "package_66db61fe" btree (speciality_id) Contraintes de clés étrangères : "package_speciality_id_4255b58fe1ae00c0_fk_speciality_id" FOREIGN KEY (speciality_id) REFERENCES speciality(id) DEFERRABLE INITIALEMENT DEFERRED Référencé par : TABLE "claimedpackage" CONSTRAINT "claimedpackage_package_id_9e1da358fbb9a46_fk_package_id" FOREIGN KEY (package_id) REFERENCES package(id) DEFERRABLE INITIALEMENT DEFERRED TABLE "package_service" CONSTRAINT "package_service_package_id_3b0ea08bfcd8da76_fk_package_id" FOREIGN KEY (package_id) REFERENCES de package(id) KEY (package_id) REFERENCES package(id) DEFERRABLE INITIALEMENT DEFERRED

Answer 1

On dirait que vous vous heurtez à ce bug documenté de Django. Le bug était triés comme non valides (et à juste titre), donc malheureusement il n'y a pas de solution propre au problème.

La contrainte d'ensemble unique dans la définition de la base de données est indiquée comme suit

"package_speciality_id_3aeb5c97679442e4_uniq" UNIQUE CONSTRAINT,
btree (speciality_id, title)

Si vous souhaitez supprimer cette contrainte, vous devrez vous assurer que l'option unique_together La définition dans le fichier de migration est cohérente avec la définition de la base de données. Essayez de remplacer le AlterUniqueTogether dans ce sens :

migrations.AlterUniqueTogether(
    name='package',
    unique_together=set([('speciality_id', 'title')]),
),

Answer 2

Juste au cas où quelqu'un rencontrerait le même problème que moi :
J'ai un système multi-locataires dans lequel chaque locataire a son propre schéma, avec l'option public schéma laissé vide.

Lorsque Django essaie d'inspecter l'état actuel de la base de données pour supprimer la contrainte unique réelle correspondant à la contrainte historique, il ne regarde que dans le fichier public en ignorant les informations relatives au schéma définies dans la section OPTIONS de la DATABASES réglage.

Il y a deux tickets ouverts concernant ce problème, sans réelle résolution en vue : #6148 y #22673 .

Vous pouvez toujours écrire votre propre backend de base de données pour contourner le problème, ou soumettre une demande d'accès à Django !

Answer 3

Il s'agit d'une alternative si la réponse de arjun27 ne résout pas votre problème.

Aujourd'hui, j'ai rencontré le même problème (mot-clé exact de la question) lorsque j'ai essayé de supprimer unique_together de Django Model. J'utilise Django 1.11.

Lire la documentation et les références de arjun27 Si je comprends bien, le processus de migration essaiera de trouver UNIQUE CONTRAINST sur Postgresql pour le champ (speciality, title) en utilisant le cas ci-dessus.

J'essaie de trouver le CONSTRAINT UNIQUE sur la table mais je ne le trouve pas.

Je crée donc le CONSTRAINT UNIQUE directement depuis la console SQL.

ALTER TABLE package ADD UNIQUE (speciality, title)

puis je réexécute la migration.

J'espère que cela vous aidera.