EntityListener pour mettre à jour des objets liés : comment "faire la cascade" ?

a marqué ce sujet comme résolu.

Bonsoir,

Ce sujet est en lien avec celui-ci, le code incriminé est dans le premier bloc secret.

J’ai une entité Lending (prêt) et une entité Piece (pièce), avec one ManyToMany bidirectionnelle de la première vers la seconde.

L’idée de base est que quand je créé un prêt, je passe le statut des pièces liées à lent. Pas de souci à ce moment-là.

Par contre, quand je clos le prêt (ce qui se traduit par l’ajout d’une date de fin, donc une mise à jour de l’objet), j’aimerais mettre le statut returned, et je n’y arrive pas avec le même listener. J’ai tenté de persister explicitement les pièces modifiées, de forcer le calcul des changesets dans l’objet UnitOfWork, mais rien à faire, seule l’entité "principale" est mise à jour en base. Je sais que j’entre bien dans mon listener, je vois les dumps que j’y mets quand je fais la clôture.

Est-ce que quelqu’un verrait ce qui me manque ?

Merci d’avance  :)

+0 -0

Bonjour Ymox,

Il ne manquerait pas un update de ton objet ?

Quelque chose comme ça :

<?php
/** @var $piece \Ysoft\InstrumBundle\Entity\Piece */
foreach ($lending->getPieces() as &$piece) {
    $piece->setStatus($status);
    $eventArgs->getEntityManager()->merge($piece);
    $eventArgs->getEntityManager()->flush();
}

J’ai essayé (j’ai même tenté persist naïvement, vu qu’à la création ça fonctionne), mais les modifications des pièces à la mise à jour d’un prêt ne se retrouvent pas dans le changeset, du moins pas par ce biais. D’où ma tentative suivante tout autant inefficace de forcer le calcul du changeset pour chacune des pièces.

Ce matin je me disais que ma relation n’est peut-être pas dans le bon sens, mais ce n’est pas non-plus fructueux.

+0 -0

Bonjour Ymox,

J’imagine que tu as bien mis un cascade => persist dans ton entité Lending au niveau de la relation ?

As-tu dumpé les entités Piece dans ton listener, afin d’être sûr que les objets soient hydratés avec les infos que tu souhaites ?

+0 -0

Oui, oui et oui  :)

Sans le premier, d’ailleurs, je pense que la modification des pièces ne serait pas effective lors de la création d’un prêt, et sans le second (toujours à la création), on ne parlerait pas du premier, et sans le troisième, rien n’aurait lieu à la création, je crois bien.

Au point où j’en suis, je vais mettre cette logique ailleurs et l’appeler explicitement dans les actions. Je ne clos pas la discussion parce que cette solution me paraît moins élégante et que j’aimerais bien comprendre, comme souvent.

Edit

Pour information, avec la logique appelée explicitement dans les actions du contrôleur, je n’ai aucun souci. Manifestement, en preUpdate, il y a lors de l’appel au listener une étape déjà effectuée qui calcule les changesets des entités liées.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte