Comment accéder à l'entityManager dans une entity

Je suis pas très clair dans mon sujet. Alors je vous explique ce que je cherche à réaliser. J'ai 2 entités :

• User
• Missions

avec une relations 1->N (càd qu'un utilisateur possède plusieurs missions).
Chaque missions à :

• une date de début
• une date de fin

Je souhaite ajouter dans mon entité "User" une méthode "getDateDisponible" qui recherche la date de fin de la dernière mission. Je voulais donc pour se faire exécuter une requête SQL qui me retournerait la date de fin maximum. Mais je pèche sur la façon pour récupérer l'entityManager dans ma classe User afin d'éxécuter ma requête SQL.

Une idée ?

je pense que cet exemple de la doc répond a ta question :

tu definis ta fonction sur mesure dans le repository

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<?php namespace MyDomain\Model;   use Doctrine\ORM\EntityRepository;   /**  * @entity(repositoryClass="MyDomain\Model\UserRepository")  */ class User {   }   class UserRepository extends EntityRepository { public function getAllAdminUsers() { return $this->_em->createQuery('SELECT u FROM MyDomain\Model\User u WHERE u.status = "admin"') ->getResult(); } }

---

et tu l'appelles dans tes controleurs :

Code:

---

1 2 3 4

<?php // $em instanceof EntityManager   $admins = $em->getRepository('MyDomain\Model\User')->getAllAdminUsers();

---

non ?

bah en fait c'est pas tout à fait ce que je cherche.
De ce que j'ai compris en vulgarisant beaucoup, les repositories sont là pour manipuler des collections d'objets entity

Moi je cherche plutôt à accéder à une propriété d'un objet entity. La différence avec ce que l'on trouve dans les exemples, c'est que cette propriété n'est pas stockée en base de donnée. Elle est calculée à partir de règles métier qui dans ce cas font appel à une requête SQL.

Sinon en écrivant ses lignes, je me dis que je peux peut-être ajouter un champs "dispoAt" et à chaque fois que je fais un insert dans la table mission, je met à jour se champs. Avec les lifeCycleCallback et un listener.

Qu'en pensez vous ?

Je pense que je pêche plus sur la conception que sur la réalisation sur le coup.

Bonjour,

Tu peux toujours créer une méthode getDateDispo

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

//User /** *@var DateTime **/ protected $dateDispo;   public function getDateDispo(){ if(null===$this->dateDispo){ $missionsIndexedByDateFin=array(); foreach($this->getMissions as $mission){ $missionsIndexedByDateFin[$mission->getDateFin()->getTimestamp()]=$mission; } $missionsIndexedByDateFin=krsort($missionsIndexedByDateFin); foreach($missionsIndexedByDateFin as $mission){ $this->dateDispo=$mission->getDateFin(); break; } } return $this->dateDispo; }

---

évidemment ce n'est pas trés optimisé puisque l'on charge toute les entités Missions, mais tu peux aussi récupérer cette valeur directement en DQL:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

//UserRepository   public function findUserWithDateDispo($id){ $dql="SELECT u,MAX(m.dateFin) FROM User u JOIN u.missions m WHERE u.id=:id";   $result=$this->_em->createQuery($dql)->setParameter($id)->getSingleResult(); //$result est tableau dont le premier index est l'entité User et le second le champ calculé. $user=$result[0]; $dateDispo=$result[1];   $user->setDateDispo($dateDispo): return $user; }

---

Aprés si tu as souvent besoin d'accéder à cette valeur et donc d'accélérer les traitements, c'est également possible de stocker cette valeur dans la base comme tu le proposes,
c'est d'ailleurs ce que suggère la doc de Doctrine:
http://www.doctrine-project.org/blog...te-fields.html
Mais avec cette méthode il y a plus de risque que la donnée "dateDispo" soit mal synchronisé, il faut penser à tout les cas de figure et n'accéder à ta base que via Doctrine .

Bonjour merci pour ce retour.

C'est ce que je cherchais. Je vais essayer avec le repository qui (je pense) va limité les problème de cohérence de donnée.

Sinon le lien que tu donnes pour les aggregate field est très intéressant. J'essayerais par la suite si le repository ne me convient pas.

Merci.