Discussion :

[fedino]

Bonsoir chèrs tous,

Permettez que nous menions cette petite reflexion sur Symfony. Voilà, je souhaite combiner le résultat deux requêtes sous symfony et afficher le tout dans un select(liste déroulante). Naturellement, il nous faut passer en SQL par UNION, la clause.

D'après mes recherches pour parvenir au même résulat sous Symfony, il faut utiliser createNativeQuery http://docs.doctrine-project.org/pro...ative-sql.html.

Le fonds du problème est que Doctrine avec EntityType est senser retourner une instance de query_builder hors la méthode createNativeQuery retourne une instance de requête native. Du coup la requête plante.

Je me demande s'il existerait un autre moyen !!! Need help please

[Nb]

Ca fait un moment que j'ai pas fait de symfo, mais doctrine ne supportant pas les UNION tu as peu de chance de réussir à utiliser un formtype étant là pour les représenter dans un formulaire; à moins que tes deux requetes tappent dans la meme table (ce qui serait louche )
A mon avis le plus simple est de définir un formtype à toi : tu pourras ainsi gerer les données qu'il prend en entrée et celles en sortie (et toutes les transformations qu'il y a entre les deux).

[fedino]

Merci Nb,

En fait, justement ci, les deux requêtes vont taper dans la même table.
Regarde .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
'SELECT a.id , a.ARTICLECODE, a.ARTICLENOM, a.ARTICLEPERISSABLE
		Article a
		LEFT JOIN TEMP_DEMANDE_ARTICLE t
		ON a.ID = t.TEMPARTICLE_ID
		WHERE t.TEMPARTICLE_ID IS NULL 
 
				UNION
 
		SELECT a.id , a.ARTICLECODE, a.ARTICLENOM, a.ARTICLEPERISSABLE
		FROM Article a
		WHERE A.ID = ?

.
La première requête avant le UNION récupère les articles qui ne se trouvent pas dans la table TEMP_DEMANDE_ARTICLE . En plus de ce resultat, j'ajoute un article donné par son Id d'où la seconde requête.

[jfsenechal]

Un or ne suffit pas dans ce cas ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
$qb = $this->createQueryBuilder('article');
$qb->leftJoin('article.tmp_demande_article, 'temp', 'WITH');
$qb->orWhere('temp.TEMPARTICLE_ID IS NULL');
$qb->orWhere('article.id', ':id')
                ->setParameter('id', $id);

[fedino]

Bonjour mon chèr,

En fait, pour ce que cas-ci oui, le Or peut effectivement faire l'affaire. Néanmoins en revenant à UNION, je me demande s'il n'ya pas moyen d'écrire cette requête avec UNION, en l'appelant par la suite dans le query_builder.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public function ArtsNotInTDem($id)
	{
		$qb = $this->_em->createQueryBuilder() ;
 
				$sub = $this->createQueryBuilder('article')  
 
							->leftJoin('article.tempdemandes', 'tda')
							->addSelect('tda')
							->orWhere($qb->expr()->isNull('tda.tempdemande'))
							->orWhere($qb->expr()->eq('article.id', ':id'))							
					                ->setParameter('id', $id);
 
                return	$sub ;
	}

[jfsenechal]

Il en parle ici

https://github.com/doctrine/doctrine2/issues/5657

[Nb]

Faire un UNION sur la meme table en selectionnant les memes champs est, au final (ptetre pas pour le SGBD), la meme chose qu'un OR.
Et dès que tu ne selectionnes pas les même champs tu tombes sur la cause même qui fait que doctrine ne gere pas les UNION.

[fedino]

Faire un UNION sur la meme table en selectionnant les memes champs est, au final (ptetre pas pour le SGBD), la meme chose qu'un OR.
Et dès que tu ne selectionnes pas les même champs tu tombes sur la cause même qui fait que doctrine ne gere pas les UNION.

La cause même qui fait que doctrien ne gere pas les UNION, c'est-à-dire...détailles un peu s'il te plait

[Nb]

Je suis pas dans la tete des dev doctine, c'est donc mon avis et il y a surement ici des gens qui pourront confirmer/infirmer mes propos.

Le DQL est un "langage" qui te permet d'interroger facilement les objets déclarés/configurés dans l'ORM (ca te donnes une vue "objet" d'un SGBD qui ne l'est pas). Les objets que tu recuperes, Doctrine est chargé de les tracker pour que tu n'aie pas à te soucier de savoir quand/comment les mettre à jour, les creer ..etc.
Mais pour ca il doit être capable de generer une ou des requetes SQL qui vont, par exemple, écrire dans la base les changements que ton code ont fait sur tel ou tel objet. Or si tu fais un UNION tu recuperes des jeux de données non homogenes : tu peux avoir, sur 2 lignes differentes, des champs venant de X tables dans la meme colonne sans que Doctrine ne soit capable de dire pour telle ligne , telle colonne c'est la colonne Y table X qu'il faudra mettre à jour si y'a besoins.
Bref dans le cas d'un union Doctrine serait incapable de connaitre avec certitude la source de donnée d'une proprieté d'un objet.

Dans ton cas les problemes liés à UNION ne sautent pas aux yeux car tu tappes dans la meme table pour recuperer les meme champs, ce qui ne devrait pas arriver car c'est un OR dans le where que tu devrais utiliser, mais ce n'est pas le cas général d'une requete avec des UNION.

[fedino]

Bien merci, à vous les gars, Nb et jfsenechal