2017-10-17 35 views
0

J'ai un étudiant d'entité qui a des sujets avec des affectations. Malheureusement, les cartographies sont étranges et je ne suis pas autorisé à changer cela maintenant, mais les devoirs savent à quel sujet ils appartiennent, et les sujets savent à quel étudiant ils appartiennent, et non l'inverse. l'étudiant ne connaît pas ses sujets, et ses sujets ne connaissent pas ses devoirs. De plus, j'ai sur onDelete = CASCADE "donc par défaut l'étudiant sera supprimé avec ses sujets avec leurs devoirs et cela fonctionne très bienEffectuez une vérification avant de supprimer un entier avec preRemove

Je veux créer un chèque si l'étudiant a un sujet avec un devoir ouvert le étudiant ne peut pas être supprimé, ni le sujet.

S'il n'y a pas de sujet ouvert, je veux supprimer l'étudiant, le sujet et l'affectation.

Comment puis-je effectuer cela? Je pense que j'ai déjà colonne vertébrale comme ceci;

public function preRemove(LifecycleEventArgs $args) 
    { 
     $em = $args->getEntityManager(); 
     $student = $args->getEntity(); 

     if ($student instanceof Student) { 
      $subjects = $em->getRepository(Subject::class)->findBy(['student' => $student]); 

      foreach ($subjects as $subject) { 
       if ($subject instanceof Subject) { 
        $assignments = $em->getRepository(Assignment::class)->findBy(['subject' => $subjects]); 

        foreach ($assignments as $assignment) { 
         if ($assignment->isCompleted()) { 
          echo $assignment." - CAN DELETE<br>"; 
         } else { 
          echo $assignment." - CAN'T DELETE, THERE ARE OPEN ASSIGNMENTS!<br>"; 
         } 
        } 
       } 
      } 
     } 
    } 

Quel sera maintenant le bon chemin à parcourir? Juste retour vrai ou faux pour arrêter ou continuer l'opération? Ou dois-je refaire des tâches spécifiques de Doctrine comme enlever, etc. Je ne suis pas sûr à 100% quoi faire ensuite.

Je dois également créer une exception personnalisée si les affectations ne peuvent pas être supprimées.

Quelqu'un peut-il aider s'il vous plaît? J'apprécierai beaucoup.

Répondre

0

Je préfère créer un service et l'utiliser chaque fois que j'ai besoin de vérifier ce type d'opérations. Malheureusement, les événements de doctrine et les auditeurs sont beaucoup trop complexes et, dans le long terme, apporteront plus de problèmes qui en bénéficieront. Bien sûr, si vous le faites "manuellement", vous devez vous assurer de déléguer ce contrôle à chaque fois à ce service et ne jamais supprimer ces objets manuellement. De plus, avoir un service rend votre code moins couplé à l'ORM lui-même.

Par ailleurs regardant votre code, il n'y a pas « d'argent réponse bullet » pour cela, mais je préférerais un qui peut être attrapée Exception (de votre type personnalisé) où vous devez savoir que quelque chose de mal est arrivé