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)