L'introduction de la contrainte de CLÉ ÉTRANGÈRE peut causer des cycles ou en cascade de plusieurs chemins. Spécifier on delete no action

De l'utilisateur, des Employeurs, des Candidats et de l'Emploi, un employeur peut créer plusieurs emplois et chaque tâche peut avoir qu'un seul employeur, un candidat peut s'appliquer à de nombreux emplois et de chaque tâche peut avoir plusieurs appliquée membres.

Ainsi, la relation est comme ceci:

Je suis en utilisant entity framework code first approche, à l'heure actuelle si je supprime un employeur, il va supprimer toutes les tâches connexes et l'utilisateur de la base de données, et si je supprime candidat, il va supprimer l'utilisateur:

modelBuilder.Entity<Employer>()
     .HasRequired(e => e.User)
    .WithOptional(e => e.Employer).WillCascadeOnDelete();

//member is candidate
modelBuilder.Entity<Member>()
    .HasRequired(e => e.User)
    .WithOptional(e => e.Member).WillCascadeOnDelete();

modelBuilder.Entity<Employer>()
    .HasMany(a => a.Jobs)
    .WithRequired(b => b.Employer)
    .WillCascadeOnDelete();

Tout fonctionne bien sauf quand je préciser de nombreux de nombreux la relation entre les candidats et de l'emploi et de la mise à jour de la base de données à l'aide de "mise à jour de la base de données", il me donne cette erreur:

L'introduction de la contrainte de CLÉ ÉTRANGÈRE 'FK_dbo.MemberJobMap_dbo.Jobs_JobId' sur la table 'MemberJobMap" peut provoquer de cycles ou en cascade de plusieurs chemins. Spécifier on DELETE NO ACTION ou de la mise À JOUR, AUCUNE ACTION, ou modifier d'autres contraintes de CLÉ ÉTRANGÈRE.
N'a pas pu créer de contrainte. Voir les erreurs précédentes.

Voici comment j'ai précisé que de nombreux de nombreux de la relation:

modelBuilder.Entity<Member>()
   .HasMany(m => m.Jobs)
   .WithMany(j => j.Members)
   .Map(c =>
   {
      c.MapLeftKey("Id");
      c.MapRightKey("JobId");
      c.ToTable("MemberJobMap");
   });

et quand j'ajoute de la migration:

CreateTable(
   "dbo.MemberJobMap",
   c => new
   {
      Id = c.String(nullable: false, maxLength: 128),
      JobId = c.Int(nullable: false),
   })
   .PrimaryKey(t => new { t.Id, t.JobId })
   .ForeignKey("dbo.Members", t => t.Id, cascadeDelete: true)
   .ForeignKey("dbo.Jobs", t => t.JobId, cascadeDelete: true)
   .Index(t => t.Id)
   .Index(t => t.JobId);

J'ai essayé de changer cascadeDelete de faux, mais qui me donne l'erreur quand je supprime un candidat qui ont appliqué des emplois ou quand j'essaie de supprimer une tâche à laquelle sont appliqués les candidats.

Comment corriger cette erreur? De sorte que:

Lorsqu'un poste est supprimé, c'est d'aller retirer associés
candidatejobmap lignes de la table sans toucher n'importe quelle autre table
Lorsqu'un candidat est éliminé, il va supprimer associés
candidatejobmap lignes de la table et de la table user en ligne sans opérer de
autre table
Tout en gardant toutes les autres effacer en cascade d'action
la même

OriginalL'auteur Mindless | 2014-12-23

11

J'ai résolu ce problème

Le problème se produit parce que j'ai deux de suppression en cascade chemin d'accès à la CandidateJobMap table:

Si je supprime employeur, sa va supprimer employeur emplois qui seront à leur tour supprimer CandidateJobMap table:

Employeur->Emplois->CandidateJobMap

Si je supprime candidat, sa va supprimer CandidateJobMap table:

Membre->CandidateJobMap

Afin de contourner ce problème, j'ai désactiver l'un de la suppression de la voie, vous ne pouvez pas spécifier WillCascadeDelete(faux) lors de la création de nombreuses de nombreuses relations, donc au lieu de vous avoir à changer la migration comme suit:
```
CreateTable(
   "dbo.MemberJobMap",
   c => new
   {
      Id = c.String(nullable: false, maxLength: 128),
      JobId = c.Int(nullable: false),
   })
   .PrimaryKey(t => new { t.Id, t.JobId })
   .ForeignKey("dbo.Members", t => t.Id, cascadeDelete: false) <--------cascade delete to false
   .ForeignKey("dbo.Jobs", t => t.JobId, cascadeDelete: true)
   .Index(t => t.Id)
   .Index(t => t.JobId);   
```
Maintenant, parce que vous définissez effacer en cascade pour de faux, quand un candidat a été supprimé, il ne sera pas effacer liées CandidateJobMap lignes, ce sera une autre cause d'erreur lorsque vous essayez de supprimer un candidat, où il est également une clé associé à CandidateJobMap, donc, vous devez supprimer manuellement les lignes associées à CandidateJobMap avant de retirer le candidat:
```
//remove all applied jobs from user, without doing this, you will receive an error
foreach (var appliedjob in user.Member.Jobs.ToList())
{
    user.Member.Jobs.Remove(appliedjob);
}

//before you can delete the user
await UserManager.DeleteAsync(user);
```
Ne sais pas si c'est le meilleur moyen, mais il a travaillé pour moi.

vous hve caché le problème, supprimer en cascade doit travailler à partir de chaque côté de la table de jointure. c'est ne pas les odeurs comme un bug dans le ER M, ou une erreur dans la façon dont vous l'utilisez.
Veuillez expliquer, parce que supprimer en cascade des deux côtés ne fonctionne pas pour moi, il me donne l'erreur que j'ai demandé
Ouais, j'ai encore plus simple d'installation avec un seul plusieurs-à-plusieurs" entité et obtenir la même erreur quand j'essaie d'activer la cascade de supprimer à la fois l'un-à-plusieurs relations en même temps. Je pense que c'est simplement une limitation de SQL Server.

OriginalL'auteur
3

Je réalise que c'est un peu vieux, mais je suis tombé sur cette même question, et il y a certains commentaires qui n'ont pas été abordés.

Spécifiquement "vous avez caché le problème..."

En Cascade de plusieurs chemins d'accès devrait travail parce que c'est valide que la suppression soit ancêtre devrait avoir pour effet de supprimer le descendant. Mais c'est seulement dans la théorie, dans la réalité, SQL Serveur, ne le permet pas, d'où l'erreur. Une solution consiste dans ce post ici la résolution de-la-sql-server-plusieurs-cascade-chemin-problème-avec-un-déclencheur.

Il suggère la suppression de tous les délinquance de la cascade des actions et de les remplacer tous avec des déclencheurs pour supprimer les enregistrements. Je préfère travailler au plus haut niveau de la cascade de la chaîne. Dans son exemple, je venais de le couper dans le "parent" de l'enregistrement avec des au LIEU DE SUPPRIMER pour les enfants et de cascade de prendre soin de tout le reste.

Je fais cela pour deux raisons
1. Il devrait être fait dans la base de données parce que c'est la dernière ligne de défense pour les données de mauvaise qualité... un peu comme vider les poches, juste avant les vêtements dans la machine à laver. En prenant soin de les choses, il signifie que vous n'avez pas à reproduire le code dans tous les différents modèles que vous pourriez développer à partir de cette DB dans l'avenir, ni ne vous devez compter sur tout le newbie devs de prendre soin d'elle.
2. à le faire en premier ancêtre permettra à toutes les autres relations de rester, y compris ceux que vous pouvez ajouter à l'avenir.
Espère que cette aide,
Mike

OriginalL'auteur

Je voudrais concevoir quelque chose comme ça..

User_Type    <-- Tow types of users Candidates and Employers     


USERS        <-- Common Fields for Candidates and Employers , along with one column to 
             -- identify if it is Candidate or an Employer referencing back to User_Type

Emp_Details  <-- Only columns that an employer will have referencing back to Users table

Can_Details  <-- Only columns that a Candidate will have referencing back to Users table

Jobs         <-- Jobs published by a user who is an employer referencing back to Users table

CandidateJobs <-- A composite key referencing back to Jobs(JobId) and Users who are
               --Candidates

Merci pour la réponse, Ma relation actuelle est très similaire à celui que vous avez suggéré, Empolyer et Candadidates sont à la base Emp_Details et Can_Details table, j'ai un tableau des rôles définis, mais je ne l'ai pas mentionné parce que je pense que ses pas à la question, je tiens à avoir des Candidats et des Employeurs à la fois référence à la même table Jobs avec des relations différentes(un à plusieurs et plusieurs à plusieurs).

OriginalL'auteur

Vous devez vous connecter pour publier un commentaire.