Discussion :

[comode]

Bonjour,

Voilà, je suis sur la PDO depuis quelques jours, j'arrive a en faire un singleton, j'arrive à utiliser le bousin mais je ne comprend pas parfaitement ce que je fait...

J'ai eu une erreur lors d'un exec() qui me proposait dans le message de mettre MYSQL_ATTR_USE_BUFFERED_QUERY sur true... Ce que j'ai fait et qui à corriger le problème...

Mais du coup, je me pose quelques questions...

- Pour commencer, n'est-ce pas une erreur d'un point de vue rigueur d'utiliser ce genre de truc ? Cela ne revient-il pas à contourner un problème et qui pourrait engendrer une surcharge de la mémoire ou quelque chose dans ce style ?

- Ensuite, je me pose des questions sur la préparation des requêtes... Il parait que ça optimise les requêtes que l'on execute plusieurs fois (je pense pouvoir comprendre pourquoi). Cependant, si on on prepare une requete, qu'on l'execute une premiere fois, qu'on en prépare ensuite une nouvelle (completement differente, sur une autre table), qu'on l'execute et que l'on veut re-executer la 1er requete... il faut forcément la re-préparer ? on perd alors toute optimisation et on ferait mieux alors d'utiliser un pdo::query ?

merci d'avance !

[rbaraer]

Pour MYSQL_ATTR_USE_BUFFERED_QUERY je ne sais pas trop, mais je peux dire qu'après un an d'utilisation de MySQL un peu avancée (vues, procédures stockées), il y a pas mal de limitations stupides, effets de bord indésirables, erreurs non signalées... Ce qui est assez agaçant.

Notamment, l'appel d'une procédure stockée qui ouvre un curseur (SELECT) ne fonctionne pas avec PDO :
- Le curseur ouvert via le SELECT est un premier curseur
- une procédure stockée retourne systématiquement un curseur avec son résultat (pourtant ce n'est pas une fonction, passons...), donc 2e curseur
- la méthode PDOStatement::nextRowset() pour lire un 2e curseur (puis un 3e...) dans PDO n'est pas encore implémentée, on ne peut donc pas lire le 2e curseur
- toute tentative d'action sur l'objet PDO suite à un appel de procédure renvoie une erreur comme quoi il reste un curseur ouvert qu'il faut lire, mais comme la méthode pour pointer sur ce curseur n'existe pas... on est bloqué

Rien que pour ça on a abandonné PDO avec MySQL et on a utilisé MySQLi. Heureusement on utilise la classe Zend_Db du Zend framework, ce qui a limité les modifs à apporter.

Pour la préparation de requête, chaque prepare() renvoie un objet PDOStatement, on peut donc récupérer $stmt1 en préparant une 1ère requête, $stmt2 en préparant une 2e, puis exécuter $stmt1 et $stmt2 avec des valeurs différentes autant de fois qu'on le souhaite, sans les préparer à nouveau (c'est bien le principe : préparer une seule fois, exécuter plusieurs fois). Il suffit d'avoir deux variables distinctes pour les 2 objets PDOStatement préparés.

[comode]

Merci pour ces précisions.

Donc en faisant fi des limitations stupides, on est - quoi qu'il arrive - limité par la portée des variables PDOstatement, de sorte a ce que si je prépare une requête dans une méthode ou une fonction, on perd toute optimisation d'un appel à l'autre si on ne stock pas ce stmt dans une variable globale ou si on l'appel dans une nouvelle instance de la class !?

[rbaraer]

on est - quoi qu'il arrive - limité par la portée des variables PDOstatement, de sorte a ce que si je prépare une requête dans une méthode ou une fonction, on perd toute optimisation d'un appel à l'autre si on ne stock pas ce stmt dans une variable globale ou si on l'appel dans une nouvelle instance de la class !?

Au niveau PHP, oui.

Par contre, les requêtes préparées sont également (et même surtout) utiles au niveau du serveur car la même requête préparée puis exécutée avec des valeurs de variables différentes sera considérée comme la "même" requête au niveau du cache du SGBD : même requête = même plan d'exécution = moins de calculs à effectuer par le serveur (le calcul des plans d'exécution est très gourmand en CPU). Ce mécanisme est valable pour Oracle (cache global + cache par session) et pour Postgresql (cache par session), mais je n'en suis pas sûr pour MySQL .

En tout cas et ce pour tous les SGBD, les requêtes préparées sont le meilleur moyen d'éviter les injections SQL.

[comode]

en gros, on peut considérer qu'il fait une sorte de hashage des requetes au niveau du cache du SGBD, ce qui lui permet de "retrouver" une requete deja construite, même si c'est un nouveau statement ?

[rbaraer]

en gros, on peut considérer qu'il fait une sorte de hashage des requetes au niveau du cache du SGBD, ce qui lui permet de "retrouver" une requete deja construite, même si c'est un nouveau statement ?

Oui c'est ça, mais chaque SGBD le gère différemment

[comode]

excellent ! donc on s'en fout un peu du coup de l'optimisation du code :p

Bon, j'exagère, mais du coup, je m'inquiète moins.