Discussion :

[Matthieu Brucher]

Mon conseil, surtout si tu apprends le C++, �cris du code par toi-m�me. Un parseur de fichier, ce n'est pas la chose la plus int�ressante en programmation. Mais ce n'est pas insurmontable non plus. Cela ne devrait pas rebuter un d�veloppeur C++, m�me d�butant.

Ce n'est pas mon avis. Le parsing de fichiers C++ est extr�mement difficile. Ce n'est pas un boulot pour un d�butant.
Je ne dis pas qu'il ne faut pas �crire des parties soi-m�me (si tu regardes bien la discussion et si tu connais un peu les outils dont on parle, il y a encore beaucoup de boulot... et je ne pense pas qu'il soit d�butant), mais non, dans le monde de l'entreprise, on ne r�invente pas la roue, ou plut�t on ne devrait pas. Il y a assez de code comme �a � �crire et surtout � maintenir pour ne pas vouloir en ajouter en plus inutilement.

[koala01]

Salut,

Moi, ce qui m'inqui�te particuli�rement, c'est que tu semble vouloir obtenir la liste des requ�tes effectivement effectu�es, avec les noms de tables, de champs et les valeurs effectivement utilis�es.

De mon avis personnel, il n'y a, a priori qu'en ex�cutant r�ellement l'application qu'il sera possible d'obtenir une liste exhaustive de ces requ�tes.

La raison est toute simple : de nombreuses valeurs (essentiellement celles qui interviennent dans les clauses WHERE, mais, peut etre aussi certaines valeurs de champs ou de noms de table) ont de grandes chances d'�tre issues de donn�es dynamiques (r�sultat d'autres requ�tes, donn�es introduites par l'utilisateur, ...)

L'analyse statique du code risque de n'en arriver qu'� te donner un r�sultat proche de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

SELECT var_champs FROM var_table WHERE var_condition

ce qui, il faut l'avouer, risque de n'avoir qu'un int�r�t relativement restreint parce que cela implique qu'il faudra alors arriver � d�terminer o� sont d�finies ces var_champs, var_table et var_conditon afin de se faire une id�e de ce � quoi cela peut bien correspondre

Et comme la d�finition de ces variables risque d'�tre dynamique, tu risques encore de te retrouver dans une situation dans laquelle var_condition (par exemple) est en r�alit� de r�sultat d'une autre requ�te dont il t'est impossible de d�terminer la teneur de mani�re statique.

J'ai donc l'impression que la meilleure mani�re de proc�der est, sans doute, de s'orienter vers un syst�me de logging des requ�tes r�ellement utilis�es et de faire tourner l'application "suffisamment longtemps" que pour obtenir un panel de requ�tes "aussi exhaustif que possible".

A partir de l�, il serait alors possible d'envisager de cr�er "quelque chose" qui soit susceptible de parser les diff�rentes requ�te et de t'afficher un r�sultat utilisable

Ce n'est pas mon avis. Le parsing de fichiers C++ est extr�mement difficile. Ce n'est pas un boulot pour un d�butant.
Je ne dis pas qu'il ne faut pas �crire des parties soi-m�me (si tu regardes bien la discussion et si tu connais un peu les outils dont on parle, il y a encore beaucoup de boulot... et je ne pense pas qu'il soit d�butant), mais non, dans le monde de l'entreprise, on ne r�invente pas la roue, ou plut�t on ne devrait pas. Il y a assez de code comme �a � �crire et surtout � maintenir pour ne pas vouloir en ajouter en plus inutilement.

+1

[ternel]

En th�orie, tu peux utiliser le pr�compilateur de GCC et un plugin d�di� pour remonter l'information souhait�e. C'est une option de cpp pour produire un xml qui m'a donn� cette piste.

En pratique, je ne connais pas cette voie, je ne sais m�me pas si c'est un bon conseil.

[koala01]

En th�orie, tu peux utiliser le pr�compilateur de GCC et un plugin d�di� pour remonter l'information souhait�e. C'est une option de cpp pour produire un xml qui m'a donn� cette piste.

En pratique, je ne connais pas cette voie, je ne sais m�me pas si c'est un bon conseil.

Mais le fait est que les requ�tes SQL sont compos�es de donn�es dynamique (tu ne peux que difficilement envisager de faire un copier / coller de toutes les requ�tes en pr�voyant toutes les variation en terme de clause WHERE, par exemple )

Tu peux, effectivement, arriver � obtenir quelques r�sultats int�ressants en faisant une analyse statique de ton code, mais le seul r�sultat que tu obtiendra sera, au mieux, compos� d'une succession (correctement d�compos�es, du moins, on l'esp�re) de noms de variables auxquels il sera difficile de rattacher une valeur.

Si "tout ce que tu veux", c'est te faire une id�e du nombre de requ�tes de type "update", "remove", "insert" ou "select" qui seront g�n�r�es, tu obtiendras ce que tu voudras, mais tu risque d'�tre d��u parce que tu verras qu'on utilise peut etre cinq tables diff�rentes, dont on ignore le nom, pour r�cupr�rer cinq ensemble de champs (dont on ignore �galement tout) en appliquant une clause WHERE et deux clauses UNION (dont on ignore tout) parce que tu n'obtiens que des noms de varaibles sans jamais pouvoir les associer � une valeur particuli�re, � moins qu'elle n'ait �t� "cod�e en dur".

Ca fait beaucoup d'inconnues, non

[Iradrille]

J'ai donc l'impression que la meilleure mani�re de proc�der est, sans doute, de s'orienter vers un syst�me de logging des requ�tes r�ellement utilis�es et de faire tourner l'application "suffisamment longtemps" que pour obtenir un panel de requ�tes "aussi exhaustif que possible".

Ca me semble une bonne piste (� moins que les requ�tes ne d�pendent que tr�s peu de donn�es dynamiques).

Pour le logging �a peut se faire de 2 fa�ons
- logguer cot� DB
- hook la (ou les) fonctions qui ex�cutent ces requ�tes (peut �tre regarder du cot� de Detours pour �a ?)

Si c'est vraiment une analyse statique que tu veux, bonne chance c'est du gros boulot, mais Lexx / Yacc peuvent �tre utile pour �a.
Ou peut �tre reprendre les sources d'un compilo genre GCC.

[koala01]

Ca me semble une bonne piste (� moins que les requ�tes ne d�pendent que tr�s peu de donn�es dynamiques).

Pour le logging �a peut se faire de 2 fa�ons
- logguer cot� DB
- hook la (ou les) fonctions qui ex�cutent ces requ�tes (peut �tre regarder du cot� de Detours pour �a ?)

A vrai dire, la solution devrait, a priori, �tre tr�s simple � mettre en oeuvre

En effet, m�me si les diff�rentes requ�tes sont g�n�r�es � des endroits diff�rents, m�me si on peut envisager le fait qu'il puisse exister une "hi�rarchie" de requ�tes, il faut se dire que toutes les requ�tes

1. se r�sument, au final, � une chaine de caract�res
2. sont, a priori, envoy�es � la base de donn�es depuis le m�me objet (la connexion � la base de donn�es )

Une fois que l'on dispose d'un syst�me de logging, il n'y a donc plus qu'une fonction (execute() ) � modifier afin de faire logger la requ�te envoy�e

Par la suite, il y a, bien sur, tout l'aspect d'analyse automatique des requ�tes r�cup�r�es, mais ca, c'est de toutes mani�res quelque chose qu'il faudra d�velopper (s'il n'existe pas d�j� des outils similaires)...

En attendant, les requ�tes qui seront analys�es seront autrement plus pr�cises que ce que l'on pourrait obtenir gr�ce � une analyse statique, quel que soit le moyen dont on les obtient

[Iradrille]

Une fois que l'on dispose d'un syst�me de logging, il n'y a donc plus qu'une fonction (execute() ) � modifier afin de faire logger la requ�te envoy�e

Plus simple � mettre en place effectivement, j'avais dans l'esprit de ne pas modifier les sources � analyser je sais pas pourquoi.

(Autre solution, toujours sans modifier les sources: sniffer et analyser les paquets en direction de la DB)