Version imprimable
Bonjour,
Dans un projet récent, j'ai besoin de réécrire la méthode buildQuery d'un module de mon admin generator.
Je m'explique :
Au lieu de laisser symfony et doctrine générer la Doctrine_Query, je voudrais brider l'affichage d'une liste d'éléments en fonction d'autres.
Le hic, c'est que j'obtiens une belle erreur ORACLE (10g) :
Any ideas ?Code:
2
Cordialement,
Mathieu
Le SQL généré n'est pas du SQL.
Ils doit te mettre le texte de la requête, compare à e que tu veux.
Bonjour Michel,
En cherchant un peu sur le net, j'ai trouvé ça : http://www.doctrine-project.org/jira/browse/DC-918
En regardant les requêtes générées, j'ai remarqué que le buildQuery générait une requête assez complexe en insérant un ORDERBY dans une sous requête ou cet élément n'était pas inclu dans le SELECT.
D'ou cette erreur du SGBD...
Pour en revenir au tracker, je ne peux pas appliquer un patch sur les classes du framework en lui-même, car je m'interdit de modifier les fichiers, qui d'ailleurs sont en "externals" !
Peut être aurez vous une piste ?
Merci de m'avoir lu !
Mathieu
L'avantage de symfony est que l'on peut modifier les classes du framework lui même, sans toucher pour autant au framework, juste en les déclarant dans le dossier lib de son application.
Mais je ne pense pas que ce soit, ici, la solution.
A priori, cela ressemblerait fort à un problème de structure (shema.yml) de la base et de construction des relations. Vérifie ton shema.yml et que les relations que tu as déclarées le soient viables. Éventuellement, s'il n'est pas trop grand, mets le ici, où juste la partie qui nous intéresse.
Merci de votre réponse Michel,
Dans un souci de confidentialité, je ne peux pas vous montrer mon schema, qui est la pierre angulaire de notre application.
Par contre, je peux vous montrer une partie de la requête SQL générée :
Le problème se situe sur le fait que lors d'un tri sur une colonne de la liste générée par l'admin-generator de symfony, la méthode buildQuery, que j'ai réécrite afin de prendre en compte d'autres facteurs, par l'intermédiaire du addSortQuery, me génére un "order by" à l'intérieur de ma sous-requête, alors que je ne voudrais que le "order by" ne soit ajouté que sur la requête principale (afin de permettre le tri).Code:
2
3
4
5
6
7
8
9
10
11
12
13
14SELECT * FROM [...] IN ( SELECT a3.agent FROM ( SELECT DISTINCT a3.agent FROM [...] WHERE a3.nom LIKE :oci_b_var_1 ORDER BY a3.prenom asc ) a3 WHERE ROWNUM <= 20 ) AND (a.nom LIKE :oci_b_var_2) ORDER BY a.prenom asc
J'ai cherché au niveau de DOCTRINE, notamment la classe "Doctrine_Query_Abstract", afin d'en comprendre le mécanisme, mais mes recherches s'avèrent infructueuses...
Merci de m'avoir lu !
Mathieu
Malheureusement, il y a trois chances sur 5 que le problème soit issu du shema.yml... sans je vais avoir du mal pour creuser.
Il faut vérifier les déclarations des liaisons dans le shema.yml.
J'ai du mal à voir l'intérêt de la deuxième imbrication de select dans la requête générée.
Je serais curieux de voir le SQL généré sur une base style MySql, plus classique dans les imbrications de requêtes.
Je n'ai jamais travaillé avec doctrine et oracle, je n'ai donc aucune idée de comment il utilise les possibilités étendues du SQL d'Oracle, mais, manifestement, il en profite.
Bonsoir Michel,
J'ai fini par contourner mon problème en désactivant le tri sur les entêtes des colonnes.
Plus de tri -> plus de "orderby" ajouté -> plus de bogue !
Merci pour votre aide...
Cordialement,
Mathieu