Discussion :

[mathieu44800]

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) :

Code :

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

1
2
 
ORA-01791: not a SELECTed expression

Any ideas ?

Cordialement,

Mathieu

[Michel Rotta]

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.

[mathieu44800]

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

[Michel Rotta]

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.

[mathieu44800]

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 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT *
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

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).

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

[Michel Rotta]

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.