Discussion :

[pc.bertineau]

J'utilise PDO par défaut, n'ayant travaillé que sur PostGre et MySQL, 2 SGBD plutôt bien supportés/interfacés. J'essaie du coup d'utiliser avec parcimonie les particularités SQL propres au SGBD sinon ça sert à rien...

Néanmoins je garde toujours sous le coude une connexion type mysql_connect pour traiter des cas spéciaux :

• Requête spécifiquement acceptée par un SGBD,
• Jointures sur des tables de bases différentes (obligations de déclarer une connexion PDO sur une DB donnée),
• Problème de perf et même bug technique (découvert sur une version 5.1.67 pour Linux, voir topic dédié).

[FMaz]

Être bien outillé
Le problème que beaucoup semblent avoir avec PDO est son manque d'intuitivité. Par défaut, les erreurs semblent ne pas être rapporté, on ne sais pas trop pourquoi ca marche et pourquoi ca cesse de fonctionner.

Donc oui, au début il est assez compliqué d'utiliser PDO. Mais la bonne nouvelle c'est qu'une fois vos "outils" développés ( une classe connexionManager offrant des fonctions de débuggage par exemple ), vous pourrez la ré-utiliser pour tous vos projet, et PDO deviens presqu'un charme.

PDO est comme un garage après un déménagement, il faut le mettre à notre goût pour s'y retrouver.


Les pommes avec les pommes
Cependant, il faut comparer des pommes avec des pommes. Je trouve un peu injuste de comparer mysql_connect avec PDO, et de dire que le premier est plus rapide. Oui, il faut s'y attendre vu que PDO est une couche supplémentaire. Ca me semble donc normal que du fait qu'il apporte des fonctionnalités supplémentaires, il soit plus rapide.

Si vous voulez réellement comparer des concurrent, il faudrait y aller PDO avec MDB2 (pear). Et dans ce cas on se rend vite compte que PDO est assez rapide, du fait qu'il soit compilé (si ma mémoire est bonnes).


Mode de connexion privilégié pour PHP6
Aussi, j'ai déjà lu quelque part que PDO allait être le mode de connexion par défaut dans PHP6. C'est donc intéressant de penser que les projets que nous commençons à développer seront plus facile à migrer dans quelques années.

Avec PDO, doit-on tout de meme mettre des mysql_real_escape

Si tu "bind" tes paramètres, non, car PDO détecte la base de données que tu utilise, et va appeler lui-même la fonction appropriée pour la base de données que tu utilise.

Si tu veux injecter directement les variables dans la requête: oui, car c'est une chaine de caractère comme une autre.

Bugs actuels:

>> Ne pas binder les valeurs de LIMIT

À moins que ca ai été résolu dans les version très récentes, évitez de binder vos valeurs pour des LIMIT:

Code :

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

LIMIT ?,?

PDO semble à un petit bug à ce niveau et englobe les valeurs dans des guillemet. Contrairement aux autres champs, MySQL ne converti pas les strings en int pour le paramètre LIMIT.

Vous devez donc injecter les valeurs de façon traditionnelle directement dans la string qui contient votre moule de requête:

Code :

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

$query = 'SELECT * FROM aaa WHERE id=? LIMIT ' . (int)$from . ',' . (int)$length . ';';

>> Pas de fonction *_num_rows()
Une raison rationnelle et expliquée existe, mais tout ce que j'en ai retenu c'est qu'il fallait faire une requête avec un COUNT() ou un count($arr) sur le résultat d'un fetchAll pour avoir le nombre de ligne d'un résultat.

C'est un peu plus long, mais dans 95% des cas ca ne me complique pas réellement la tâche.

>> closeCursor() n'est pas toujours efficace
Si vous ré-utilisez une variable de requête préparée pour une 2ieme requête, il arrive parfois que malgré un closeCursor, la variable ne soit pas correctement ré-initialisé.
Prenez l'habitude de terminer avec $prep = NULL; , ce qui libère réellement la variable de son contenu.

[Rakken]

Le problème est que cette liste des bugs actuels n'est hélas pas exhaustive.
Allez voir sur php.net la page "PDO Oracle", ça fait peur... pour un outil qui se veut être utilisé pour s'abstraire en partie de la base de donnée. (Perso, je n'ai jamais bossé en web réellement que sur deux bases, MySql et Oracle, si l'une des deux ne fonctionne pas (ne soyons pas mauvaise langue, disons juste "très mal") avec pdo... à quoi bon ?).
Et pour ce que j'en sais, ce n'est plus maintenu, sur PECL la date de la derniere mise à jours est de 2005.
Qu'ils veulent mettre ca en avant pour PHP6, pourquoi pas, mais pour l'instant, c'est du bricolage.

Juste un exemple, le type CLOB n'est même pas supporté par pdo-oci (il y a bien les objets LOB, mais ils fonctionnent comme des fichiers, super pratique quand on veut faire un insert avec un texte de 5000 caractères, il insérer la ligne puis ouvrir le champ comme un fichier et écrire dedans à coup de write ).
Et ça, c'est sans compter les seg fault (si si si), qui se produisent dans certains cas foireux (je n'ai plus le code en question, mais une fois sur deux, ma page web devenait complètement blanche parce que l'appel à pdo_oci provoquait un plantage).

Bref, je persiste, PDO en l'état actuel, je n'en veux pas. Se faire une petite classe d'abstraction à la main qui appelle directement les mysql_xxx et autres est tout aussi efficace et, même si c'est étrange, plus robuste.

Tu parles d'une classe à rajouter par dessus PDO pour le rentre à peu prés utilisable, génial, alors puisqu'il y a des trucs qu'il faut rajouter de toute manière, pourquoi s'encombrer de PDO ?

[CinePhil]

Je m'initie désormais au Zend Framework et toute l'abstraction qu'il contient me fait un peu peur parce que j'aime bien avoir la main sur les requêtes.

Zend Framework utilise t-il PDO ou directement les mysql_X, pg_X... ?

[sabotage]

t pour ce que j'en sais, ce n'est plus maintenu, sur PECL la date de la derniere mise à jours est de 2005.

PDO ne fait plus partie de PECL.
Je ne saurais pas me prononcer sur Oracle mais concernant mysql et mssql, je n'ai rencontré que peu de problème et des bugs existants sont corrigés.

Pour le sujet de la production d'un code universel, comme on l'a dit, le problème se situe bien en amont de PDO puisque les différents moteurs ne parlent pas la même langue.
Un des interêts de PDO est que l'écriture des traitements est uniforme, une couche d'abstraction quoi

[FMaz]

ma page web devenait complètement blanche parce que l'appel à pdo_oci provoquait un plantage).

Généralement quand ca m'arrivait, s'était parce que:
1- Je n'avais pas configuré PDO pour afficher les erreurs
2- Je n'avais pas correctement ré-initialisé la variable contenant le statement.

Ce qu'il faut comprendre, c,est que par défaut, PDO est en mode "production", et non en mode "développement". Si on veux afficher les erreurs, il faut rajouter un paramètre pour lui dire de façon explicite.

Tu parles d'une classe à rajouter par dessus PDO pour le rentre à peu prés utilisable, génial, alors puisqu'il y a des trucs qu'il faut rajouter de toute manière, pourquoi s'encombrer de PDO ?

Ca c'est peu de la mauvaise foi. La classe à rajouter par dessus sert uniquement à pouvoir mieux débugger. Elle n'est pas requise en production.

De plus tu parle d'un session manager, et bien ce n'est pas le rôle de PDO ni de n'importe quel autre mode de connexion. Pour finir, avoir un session manager n'est absolument pas obligatoire.

Moi j'aime mieux ca, car ca me permet d'accéder à n'importe laquelle de mes session peu-importe le scope dans lequel je suis, et ca me permet aussi d'automatiser ma gestion des erreurs.

Je ne vois pas en quoi l'envoi de email en cas de problème de requête devrait être pris nativement en charge par PDO, ou n'importe quel autre mode de connexion.

Pour le sujet de la production d'un code universel, comme on l'a dit, le problème se situe bien en amont de PDO puisque les différents moteurs ne parlent pas la même langue.

Exact, entre beaucoup de systèmes, il y aura des différences. Mais PDO permet de mâcher une bonne partie du travail de base pour les language avec une syntaxe SQL.

Après, pour le --somme toute petit-- pourcentage restant, avec ou sans PDO, vous devrez traiter le cas manuellement de toute façon.

[pc.bertineau]

Après, pour le --somme toute petit-- pourcentage restant, avec ou sans PDO, vous devrez traiter le cas manuellement de toute façon.

C'est peut-être le côté "pervers" de PDO : laisser croire que l'interopérabilité est possible. Mais pour du CRUD de base, il y a un intérêt certain à l'utiliser.

[FMaz]

Effectivement, beaucoup de gens semblent penser que toute requête imaginable sera fonctionnelle et traduite à 100%. Ce n'est malheureusement pas la réalité du moment, et je doute que ca soit possible un jour, peu-importe la couche d'abstraction.

Personnellement, je trouve PDO pratique car je n'ai pas à faire ce qui suit, ni à programmer moi-même une classe pour s'en occuper automatiquement (ce qui devrait être interprété, donc plus lent que PDO qui est compilé nativement)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
switch($db_type)
{
   case 'sqlite':
       $param1 = sqlite_escape_string($_POST['param1']);
       break;
   case 'mysql':
       $param1 = mysql_escape_string($_POST['param1']);
       break;
   case '...'
        $param1 = ..._escape_string($_POST['param1']);
        break;
}
$query = "UPDATE foo SET bar=\"$param1\";";

PDO automatise ce genre d'opération de base à très bas niveau. Pour moi (et je ne suis pas tous), c'est un des gros avantage de PDO.

Un autre autre avantage est la possibilité de pouvoir binder des valeurs, ca fait des requêtes plus propres. Certaines personnes pourraient dire que sprintf() peut aussi placer des valeurs dans la chaine, mais le problème c'est qu'avec 35 valeurs à placer pour un gros INSERT, on s'y perd vite si on ne peux pas nommer les 'tags'.

PDO m'oblige à avoir un code plus propre, et chaque requête deviens un bloc de code bien défini.


Pour finir, je dirais qu'il fut un temps ou je détestais la POO. J'affirmais qu'avec une bonne organisation de fichier, et une bonne convention de nommage, s'était inutile. Je poussais même la critique en affirmant que vu qu'en procédurale pure, on ne segmentait pas tout le code en l'isolant dans des méthodes d'objets, on pouvais plus facilement optimiser ce code afin de grouper plusieurs actions en même temps.

Je pense toujours que j'ai partiellement raison. Cependant je pense que la POO apporte des avantages non-négligeable du point de vu de l'ergonomie, du contrôle d'accès (private, protected, public), et une foule d'autres petits avantages pas nécessairement nécéssaires, mais tout de même très apprécié et qui facilitent le développement.

PDO, c'est comme la POO: à strictement parler, c'est pas essentiel, mais quand on apprend à aimer toutes ces petites subtilités, on ne veux plus la laisser partir. (9 jours plus tôt et je terminais sur une bonne blague )

Si mon paragraphe sur l'amour ne vous convainc pas, voici une compilation d'extraits portant sur PHP6:

Suppressions

Cette fois-ci, PHP6 fait le ménage en supprimant (pour ceux qui ne savent pas) : Les Register globals, Magic quotes, Safe Mode, PECL (qui pourra être téléchargé, mais absent dans le package officiel de PHP6).

Certaines extensions les moins utilisées migrent vers PECL mais aussi celles des bases de données laissant cette fois la place à PDO que nous introduirons plus tard...

Src.: http://www.slashon.com/index.php/200...-_Vous_adapter

Dans cette nouvelle version de PHP, les fonctions telles que mysql_connect seront toutes déportées dans PECL (un dépôt d’extensions PHP non obligatoires) pour laisser la place à PDO. Ce changement majeur va forcer bon nombre de développeurs à se mettre à jour, et à ne plus utiliser les fonctions de mysql_* au profit de l’extension PDO.

src: http://manuel-esteban.com/?p=31

[sabotage]

Oui enfin c'est un forceage au rythme du web : dans 10ans on aura toujours des hebergeurs avec l'extension mysql (PHP5 a 6 ans).

[Rakken]

En même temps, virer de base toutes les extentions mysql_* c'est rendre incompatible l'immense majorité des sites utilisant une base mysql.
Sur une appli bien faite (avec une classe d'abstraction qui concentre tous les appels au fonctions mysql_* au même endroit), ce n'est pas forcement difficile de migrer, mais pour le reste...
A vouloir faire "trop" propre, je me demande si php6 ne va pas tout simplement rebuter. Il n'y a qu'a voir la lenteur de migration entre php4 et php5 alors que php5 était vraiment nickel en termes de rétrocompatiblité (sur une dizaine de sites de taille parfois importante que j'ai eu à migrer, aucun n'a pris plus d'une journée, et la moitié d'entre eux n'ont nécessité aucun changement).
'fin bref, puisqu'il faut manger du PDO, je mangerai du pdo. Encore une fois, avec une petite couche bien faite dessus, on ne se rend plus compte de ce qu'on utilise.

[FMaz]

J'essaie de me mettre à PDO et je me demande si ça vaut le coup que je continue...

Portabilité ?
D'après ce que j'ai pu lire, elle est très relative, à cause des particularités du langage SQL implémenté par chaque SGBD.
En plus je n'en ai pas besoin puisque c'est pour une application personnelle.

La portabilité se situe au niveau des fonctions d'accès, pas au niveau de la formation des requêtes SQL.
Il s'agit de 2 couches d'abstraction bien distinctes.

En ce qui concerne la difficulté d'exploitation avec MSSQL ou Oracle, il faut savoir que oui, ces connecteur en particuliers ne sont pas encore complété. Mais comme PDO est la direction dans laquelle PHP va évoluer, c'est un bon réflexe de l'utiliser afin que dans quelques années, la portabilité s'élargisse au niveau des autres SGBD.

C'est comme le CSS3: On en met, et dans quelques temps, les vieux site auront des fonctionnalité de plus qui apparaitrons :p

Performance ?
D'après ce que j'ai pu lire également, il semblerait que PDO puisse être nuisible à la rapidité de l'application.
Pour le moment, ce ne sera sûrement pas sensible dans mon appli mais à terme, j'aurai potentiellement des dizaines de milliers de lignes dans 27 tables, voire davantage.

Moins que n'importe quel autre mécanisme d'abstraction des fonctions d'accès à la base de données, car c'est la seule extention qui est compilée nativement.

Après il faut comparer des pommes avec des pommes, et savoir relativiser les "moins performant".

Fabien potencier expliquait assez bien cette réalité lors d'une conférence lorsqu'il comparait la rapidité de Symfony à faire des hello world. La facon la plus rapide de faire un hello world, c'est die('hello world');

Mais on repassera pour la souplesse du code.

Facilité ?
Je me disais que d'avoir des classes toutes faites pour gérer le dialogue avec la BDD pourrait me faciliter la vie.
J'ai trouvé aujourd'hui sur DVP une autre extension de PDO qui permettrait semble t-il de combler un manque pour débugguer les requêtes (je ne l'ai pas encore essayé), alors qu'avec la méthode traditionnelle, un simple echo $requete donne la requête réellement envoyée au serveur.

Oui, c'est à mon avis la faiblesse #1 de PDO.
Ceci étant dis, dans quel cas est-ce nécéssaire d'avoir cette information ?
- Au moment de la création de la requête
--> Créée la dans PHPMyAdmin
- En cas d'erreur.
--> L'erreur retourné par MySQL retourne la portion provoquant l'erreur. Il suffit de capturer l'exception.

Mais je suis d'accord, ce n'est pas parfait, et je l'ai déjà dis dans un autre sujet.

Ensuite lorsqu'on comprend bien le fonctionnement des placeholders, on comprend assez vite que d'avoir la sortie complète de la requête est inutile, puisque le bug ne proviendra pas de la valeur placée par le place holder. Certe, il faut faire confiance à PDO, et bien savoir ce que les différents PDO:ARAM_xxx font.

L'extrait de l'erreur lancé par mysql suffit généralement à remplir le trou d'information manquante s'il y en as un.

Et puis finalement, vous comparé l'exécution d'une requête simple avec une requête préparée. Avez-vous déjà fait des requêtes préparé avec mysql_ ou mysqli_ ?

... parceque query et exec en PDO retourne aussi le résultat complet, mais ce n'est pas des requête préparés.

Donc en somme, une partie du problème est que vous utilisé une autre facon de transiger avec MySQL. Une requête préparée se fait en 2 partie, et seul MySQL assemble les 2 résultats. Riens à voir avec PDO.

Encore une fois, comparez les pommes à des pommes.

Faut-il donc que je persiste à comprendre comment fonctionne ce foutu machin parce que c'est l'avenir PHP6 ou autre raison fondamentale, ou existe t-il une classe d'accès à une BDD Postgresql plus simple que PDO ?

Sans aucun doute. PDO vaux tout à fait la peine d'être appris malgré qu'il ne soit pas aussi intuitif au départ que mysql_ ou mysqli_ .

Le code sera plus propre, plus sécur, et normalisé.

Maintenant que je me suis fait un connexion manager et que j'ai développé mes classes étendu de PDO et PDOStatement et intégré une gestion automatisé des erreurs: je suis vraiment heureux, ma vie s'est grandement améliorée. PDO à même guérrit ma grippe.


Donc voilà, amusez-vous !

[FMaz]

En même temps, virer de base toutes les extentions mysql_* c'est rendre incompatible l'immense majorité des sites utilisant une base mysql.
Sur une appli bien faite (avec une classe d'abstraction qui concentre tous les appels au fonctions mysql_* au même endroit), ce n'est pas forcement difficile de migrer, mais pour le reste...
A vouloir faire "trop" propre, je me demande si php6 ne va pas tout simplement rebuter. Il n'y a qu'a voir la lenteur de migration entre php4 et php5 alors que php5 était vraiment nickel en termes de rétrocompatiblité (sur une dizaine de sites de taille parfois importante que j'ai eu à migrer, aucun n'a pris plus d'une journée, et la moitié d'entre eux n'ont nécessité aucun changement).
'fin bref, puisqu'il faut manger du PDO, je mangerai du pdo. Encore une fois, avec une petite couche bien faite dessus, on ne se rend plus compte de ce qu'on utilise.

Probablement que les hébergeur vont offrir les 2 types d'hébergement: 5 ou 6.

mais beaucoup des fonctionnalité de PHP6 ont été, ou vont être prévu pour des version de php 5.x. Par exemple, php 5.3 propose beaucoup de fonctions qui étaient initialement prévu pour PHP6, et déjà certaines fonction lancent des warning E_DEPRECATE. Comme les fonction ereg_* je crois.

Oui PHP6 va clasher, mais c'est une bonne chose, car PHP souffre de la réputation d'être un language amateur. Il n'est pas toujours pris au sérieux pour les gros développement d'envergure importante.

... et c'est principalement du au fait que plusieurs personnes programment mal et profite du fait que PHP soit laxiste pour faire passer n'importe quelle cochonnerie comme du code "fonctionnel".

Les magic quote ont été, selon-moi, le point tournant ou l'équipe de PHP à décidé de mettre un frein à "faciliter la programmation amateur", et s'est dit qu'il fallait au contraire ré-axer le projet vers un avenir plus sérieux.

Donc c'est vrai que PHP6 ne sera pas aussi largement déployé que les versions précédentes si les conditions actuelles sont maintenues. Par contre, je pense que dans la culture du milieu, on vera apparaitre:

PHP 6 = professionel
PHP 5 = amateur

==> Si l'application ne migre pas, c'est un indicateur d'une programmation bâclée, ou d'un programmeur peu compétent.


Note: Je suis le premier qui devra sans doute adapter certaines parties de son code Mais je vous jure que j'ai été ammené à travailler sur des horreurs de programmation, et que l'avènement de normes plus stricte est pour moi un véritable soulagement.

[sabotage]

Je ne comprends pas bien ce que tu dis.
Tu veux dire que les requêtes préparées avec mysqli ou avec PDO ne fonctionnement pas sur le meme principe ?

[FMaz]

Ce que je dis, c'est que les gens comparent des requêtes directes (mysql_query) avec les requêtes préparés de PDO.

Dans un cas, on envoie une unique chaine string à MySQL. Évidemment que c'est facile de l'afficher.
Dans l'autre cas, c'est un autre concept: c'est une requête préparé:
On envoi un "moule" de requête au serveur, qui la stock temporairement j'imagine (je connais pas les détails internes), puis dans un second temps, on envoi les paramètres et l'ordre dans lequel les placer les valeurs (dans les place holder), et d'exécuter la requête ainsi forgée.

Alors pour obtenir la requête complète et construite, il faudrait que MySQL retourne le résultat de la compilation qu'il fait.

-------

Pour faire une analogie, c'est comme si on reprochait aux Vues MySQL ne ne pas nous laisser facilement débugger la requête qui se cache derrière la vue...


Edit:

En quoi ce code MySQLi permet-il d'avantage de débugger la valeur totale d'une requête que PDO ?:

Code :

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

1
2
3
4
5
6
 
$city = "Amersfoort";
$mysqli->prepare("SELECT District FROM City WHERE Name=?");
$stmt->bind_param("s", $city);
$stmt->execute();
//...

Je ne vois pas plus comment vous arrivez à obtenir:

Code :

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

1
2
 
SELECT District FROM City WHERE Name='Amersfoort';

... et je me demande même au moins une personne sur la terre a déjà fait des prepared statement avec mysql_ tellement c'est manuel et pénible.

[sabotage]

En quoi ce code MySQLi permet-il d'avantage de débugger la valeur totale d'une requête que PDO ?:

Oui donc mysqli et PDO pour les requêtes préparées c'est la même chose.

[FMaz]

Oui donc mysqli et PDO pour les requêtes préparées c'est la même chose.

Exact.
C'est pour cette raison que je trouvais les gens dur dans leurs critiques envers PDO, qui souffre exactement du même défaut que les autres.

[Invité]

Bonjour,
J'ais comme l'impression que tout le monde a raison et tout le monde a tort
Mysqli et pdo tel que je le vois utilisé partout font la même chose

Effectivement puisque je ne sais même pas si j'ais vu une seule fois ici "un vrais prépare de PDO" a savoir que dans la log "SQL" nous trouvons
l'appel du prepare, (une ligne)
puis l'exec (une autre ligne par exec) !

Faute de quoi PDO perd 50% de son intéret

Oui tout est dans

Code :

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

$dbd->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Avant de poster j'ais recherché, il me semble que JulP a abordé le sujet

[FMaz]

À mon sens, il est assez rare que les gens utilisent prepare pour des raisons de pure-performance.

La raison principale pourquoi prepare est autant "fortement suggéré", c'est pour prévenir le plus possible les injection SQL, tel que l'OWASP l'avait d'ailleurs suggéré.

Donc oui, très utile à savoir (même moi je l'ignorais), mais pas si "choquant", vu qu'au final ca ne change pas grand chose... même qu'un prepare pour une seule exécution, c'est plus lent qu'une requête direct...

[stealth35]

avec PDO on peut créer notre propre pilote en PHP
http://pecl.php.net/package/pdo_user

c'est ici que les constantes PDO::PARAM_EVT_* seront utilisées