Vérifier si une entité est déjà présente en base

Sur base d'une contrainte d'unicité, pas de son ID

Le problème exposé dans ce sujet a été résolu.

Bonjour à tous !

Une fois de plus, je me tourne vers vous pour un cas un peu particulier.

J'ai une entité sur laquelle j'ai une contrainte d'unicité basée sur plusieurs champs, représentant une action faite par un utilisateur. L'idée étant que ces actions doivent donc être uniques. Maintenant, il n'est pas impossible que ce qui fait enregistrer cette action survienne plusieurs fois. Mais ce que j'aimerais, c'est donc savoir si je risque de créer un doublon ou si je peux persister sans crainte. Certes, je peux m'amuser à persister et englober le tout dans un try/catch (c'est probablement ce que je vais faire en attendant), mais ça me paraît vraiment bourrin.

Il n'y a pas une méthode qui permettrait de "valider" une entité créé programmatiquement afin de justement tester et éviter le traitement d'une erreur ?

Merci d'avance

+0 -0

Justement, c'est une validation qui passe depuis un formulaire, pas quand l'entité est créé entièrement par programmation.

J'avais pensé à ça, d'ailleurs la contrainte de validation est présente, mais ça n'empêche pas Doctrine de persister (logique, la validation n'est pas du domaine de Doctrine).

+0 -0

En fait c'est assez simple, il suffit de faire le check à la main (ce que fait le validator).

C'est forcément plus joli avec un service qui s'en occupe.

Mais après, si tu es sûr que l'entité va exister dans l'exécution courante uniquement en doublon, tu peux utiliser le unitofwork de doctrine qui contient toutes les entités, et si tu fais une interface genre equalable tu vas pouvoir tester que ton objet est identique facilement, même si tu ne l'as pas persisté (c'est une approche un peu java).

En espérant t'avoir aider :-) .

Merci Nek

Je ne pense pas qu'utiliser le unitOfWork me sera utile, parce que je ne crois pas qu'il contienne aussi les entités déjà persistées. En fait, c'est un travail qui sera lancé par un cron, et c'est à chaque exécution de ce dernier qu'il risque d'y avoir doublon. Entre deux, j'imagine volontiers que les entités "persistables" l'auront été.

Du coup, je vais voir pour reconstruire/récupérer la contrainte et valider à la main  :)

+0 -0

Ma foi, la contrainte faisant appel au repository de façon relativement simple… Tu n'as pas grand chose à faire, mis à part utiliser ton repository :p . (rien n'est magique avec sf2!)

En fait le UnitOfWork aurait été utile si t'avais été dans la même exécution de page, mais bon du coup si t'es sur un cron, en effet…

Donc plutôt que de faire simplement $entityManager->persist() (ce que je fais actuellement), je peux faire $repository->persist(), c'est ce que tu es en train de me dire ?

Edit

Ah, je comprends  :honte:

M'enfin, je pensais quand-même qu'il y aurait une méthode déjà prête pour ce genre de cas.

+0 -0

Ah non désolé, mis à part catcher l'exception (ce que tu peux faire et qui n'est pas forcément catastrophique, vu que dans les deux cas t'as une requête) il n'y a pas de truc prévu. Il faut juste être sûr d'avoir la bonne contrainte.

+1 -0

[…] catcher l'exception (ce que tu peux faire et qui n'est pas forcément catastrophique, vu que dans les deux cas t'as une requête) […]

Nek

Pas faux  :p

Je verrai à l'occasion si ça consomme plus de ressources de traiter l'exception (c'est probable que ce soit cette version la plus gourmande) ou de faire la requête à la main et tester son retour. Là, de toute manière, on est désormais en production.

+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