Produits Entr'ouvert » Passerelle

Voir l'option unique_together¹ dans Django.

¹ https://docs.djangoproject.com/en/dev/ref/models/options/#unique-together

Ok le type de service n'est pas un champ, c'est une table. Vous l'avez dans l'os, à moins de déplacer le champ slug du modèle parant au modèle enfant. Ça vous sert encore à quelque chose d'utiliser l'héritage ? J'ai l'impression qu'il n'y a rien de générique et dans ce cas vous pourriez migrer vers de l'héritage abstrait et rendre slug unique.

Comme on est pas dans un monde idéal je rendrais simplement le champ slug unique tout court, je ne vois pas bien la conséquence.

Autre possibilité c'est de tester ça dans le clean du formulaire d'édition, mais ce n'est pas 100% secure sans changer le niveau d'isolation de la base à serialized; dans votre cas ce ne serait pas gênant (dans une application où il y a beaucoup d'écriture ça fait des bugs étrange pour les utilisateurs voir calebasse).

Bon, ça doit pouvoir se jouer avec unique=True dans le champ slug de BaseResource. Mais ça va impacter toutes les applications, il faut donc toutes les migrer (au sens "south").

1. créer les migrations "initiales" pour les applis qui n'en ont pas
2. faire un migrate --fake
3. faire la mise à jour du slug avec unique=True
4. faire un migrate

• pour chaque application, lors du init.d :
  1. si la table n'existe pas, on syncdb --migrate --fake l'application
  2. si la table existe mais que y'a rien dans l'historique south, on migrate-fake le 0001_initial puis on migrate.

Le bug pour les migrations initiales existe déjà, #4696.