Officiellement, vous n'avez aucun contrôle sur l'ordre des opérations en cascade. Vous pourrez peut-être abuser de certains sans papiers comportement cependant :
- pour MySQL 5.5, les clés étrangères sont exécutées dans l'ordre dans lequel elles ont été créées, donc supprimez et recréez le
fk_category_org-la contrainte devrait fonctionner - pour MySQL 5.6+, les clés étrangères sont exécutées dans l'ordre lexical de leurs noms, donc en renommant
fk_category_orgà par ex.fk_z_category_orgdevrait fonctionner
Ceci n'est pas documenté et peut changer à tout moment (et peut être influencé par d'autres facteurs).
Cela étant dit, la bonne façon de faire cela (et toute autre chose trop compliquée pour on cascade ) serait d'ajouter un before delete -déclencheur
sur votre organisation -table qui supprime "manuellement" les utilisateurs d'abord, puis les catégories ensuite. before delete -les déclencheurs sont exécutés avant on cascade (afin que vous puissiez décider si vous souhaitez les conserver ou non, même si cela serait probablement trompeur).
Il n'est pas tout à fait clair si c'est votre comportement intentionnel, mais actuellement, un utilisateur peut avoir une catégorie qui appartient à l'organisation 1 alors qu'il est affecté à l'organisation 2. La suppression de l'organisation 1 échouerait alors toujours. Il semble un peu que c'est ce que vous voulez empêcher par votre conception, mais si vous voulez que la suppression fonctionne également dans ce cas, vous avez besoin pour utiliser le déclencheur pour pouvoir l'incorporer (ou le supprimer manuellement dans votre application), la cascade ne fonctionnera que si vous cascadez également dans la table des catégories.
