# PHP > PHP & Base de donnes > [PDO] Comprendre PDO [Tutoriel]

## FMaz

Bonjour  tous.

Je viens de complter un article portant sur ... PDO !
Bien qu'il existe plusieurs articles du genre, je trouvais que la plupart expliquaient d'avantage comment utiliser PDO, mais rarement le pourquoi des choses. Ainsi, j'ai essay de crer un article qui va au fond des choses en me remmorant tout ce que j'ai pus trouver complexe  saisir par moi-mme au dbut.

J'ai aussi tent de cibler les principales incomprhensions que j'ai constat sur le forum, et d'tayer des rponses les plus simples possible. Il s'agit donc d'un article de niveau dbutant/intermdiaire.


Pr-requis  la lecture:
- Une base en PHP
- Une base avec les fonctions mysql_ ou mysqli_
- Un peu de temps  :;): 

Voici donc l'article en question:
http://fmaz.developpez.com/tutoriels...omprendre-pdo/


Vos commentaires seront les bienvenu !

----------


## sabotage

Une petite coquille : "l'extension MySQL a fait son temps. "

Sinon ce genre d'articles est ncessaire car on voit bien sur le forum que mysql_ qui est le pire choix des trois reste largement utilis.

----------


## FMaz

Merci pour la coquille, c'est dj corrig  ::): 

Et ouais, c'est aussi ce que je me disais... En fait j'ai constat que beaucoup de gens ne comprennent mme pas ce qu'est une requte prpare, et qu'ils pensent que c'est une particularit de PDO... 

Et que d'autre pense que les requtes prpars sont "l'unique" facon de faire une requte avec PDO: et que c'est beaucoup plus long qu'un mysql_query().

Alors voil, je voulais abattre ces quelques prjugs trop souvent mal expliqus.

----------


## pc.bertineau

Bonjour,

J'utilise PDO depuis longtemps et je trouve votre article bien rdig, en expliquant bien ce qu'est et ce que n'est pas PDO...

J'ai une question  propos :

Pour des insertions massives en base, j'utilise le plus souvent les requtes prpares sans les fonctions "bind" mais en passant directement un tableau de valeurs  la requte prpare :



```

```

Je me suis auparavant assurer du bon type des valeurs passes en paramtre. Mais je me demande si cette utilisation protge des injections SQL ?

----------


## Doksuri

bon petit article..simple et clair
moi qui me mettais doucement a PDO... je vais abandonner les autres maintenant xD

 ::ccool::

----------


## RunCodePhp

Salut

Je lis actuellement avec beaucoup d'attention cet article.
Excellent travail, faut le dire.  ::ccool:: 

J'en ai donc mme termin que je me suis empress d'essayer cette ligne :


```
$arrExtraParam= array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8");
```

Et l j'obtiens une erreur comme quoi la constante de classe MYSQL_ATTR_INIT_COMMAND n'existe pas.  :8O: 

J'ai beau plucher toutes les constantes PDO au niveau de la Doc, je ne la vois pas effectivement, et rien permettant de la remplacer.
Je vois quand mme celle ci : MYSQLI_INIT_COMMAND, donc pour MySQLi.
Malgr tout, ce n'est pas une constante de classe de PDO.

As tu eu cette erreur ?
Personnellement je n'est pas d'ide du comment exploiter cette technique, actuellement j'effectue un PDO::exec('SET NAMES utf8').

----------


## FMaz

> J'en ai donc mme termin que je me suis empress d'essayer cette ligne :
> 
> 
> ```
> 
> ```
> 
> Et l j'obtiens une erreur comme quoi la constante de classe MYSQL_ATTR_INIT_COMMAND n'existe pas.


Bon alors oui la constante existe bien, voir: http://php.net/manual/fr/ref.pdo-mysql.php

Note au passage concernant le fait que PHP exige des valeur entire: comme valeur, on peut mettre "SET NAMES utf8" ou l'entier 1002, ca reviend au mme.

Sinon tu peux simplement faire ceci:
$db->query("SET NAMES 'utf8'");

Edit: Sinon je recherche un peu, je crois avoir lu qu'il y avait un bug avec PHP 5.3 quelque part.
Edit2: Ah voil le bug en question: http://bugs.php.net/bug.php?id=47224 . En bref: c'est un bug dans php 5.3.0, et c'est corrig dans la version 5.3.1.


---------------




> Pour des insertions massives en base, j'utilise le plus souvent les requtes prpares sans les fonctions "bind" mais en passant directement un tableau de valeurs  la requte prpare :
> 
> 
> 
> ```
> 
> ```


Hum, je suis un peu hsitant. La pratique est tout  fait lgitime, et il n'y a rien de mal  ne pas utiliser les mthodes de binding. Cependant, pour tre honnte, je ne sais pas trop.

Mais si tu ne mentionne rien, je crois ( valider) que par dfaut la protection devrait tre de type STRING pour toutes tes valeurs... (Tu pourrais essayer de reproduire le faux-bug du limit pour voir si c'est bien le cas)

De plus, j'aimerais faire une mise en garde que l'utilisation des requtes prpare n'est pas une protection absolue contre les injections. Vous devez tout de mme valider vos entrs. (Donc si tu les a bien valide comme tu le dis, il ne devrait pas y avoir de problme).

----------


## stealth35

le bind ca sert surtout avec FETCH_BOUND.

----------


## RunCodePhp

> Note au passage concernant le fait que PHP exige des valeur entire: comme valeur, on peut mettre "SET NAMES utf8" ou l'entier 1002, ca reviend au mme.


Oui, je m'en suis dout que cette constante retournerait un entier, mais vu quelle n'existe pas de mon cot (bug, surement), je ne voyait pas quelle valeur.

J'ai remplac comme ceci :


```

```

Il n'y a certes plus d'erreur, mais je ne suis pas en UTF-8 pour autant.  ::aie:: 

Bon, si tu as une ide, tant mieux, sinon je chercherais un peu plus longuement un autre jour.
Pour le moment ce n'est franchement pas important, c'tait plus par curiosit.  ::P: 

Merci et excellent article encore une fois.  :;):

----------


## gene69

bonjour

quatres observations:
les remerciements dans le texte, c'est pnible  lire,  la fin, c'est bien.un argument plus dtaill sur la gestion des exceptions par PDO aurait flatt le lecteur curieux et non pratiquant que je suis, parce qu' l'heure actuelle, une surcouche maison peut trs bien s'occuper de protger les donnes de faon aussi efficace.  part allger la syntaxe...pourquoi PDO si mysqli est plus performante aujourd'hui? J'en ai rien a faire d'une extension qui fonctionnera bien dans 5 ans pour mes dveloppements d'aujourd'hui.comment obtenir une trace sql avec PDO? a fait parti des pralables sur lequel je ne suis pas prt  transiger. J'ai besoin d'une trace sql au niveau applicatif, mes bases ne voient gnralement qu'un seul utilisateur, or il y en a plein dans la vraie vie. or jusqu' prsent, la classe d'accs aux donnes est un terrain stratgique pour espionner l'utilisateur.

l'article est clair et c'est un bon travail, merci.

----------


## hornetbzz

Bravo, vraiment trs bien, complet, trs facile  lire et  comprendre, mme pour un noob comme moi.

L'intrt de PDO est expliqu objectivement, a laisse le choix au lecteur en connaissance de cause.

La "passerelle" avec mysql est bien explique et les comparatifs sont explicites, ce qui peut aider  franchir le pas.


J'ai juste 2 petites remarques :

1) Remarque perso: a aurait t bien de parler un minimum des singletons, me semble-t-il. En tous cas en ce qui me concerne, pour avoir bien galrer avec ce sujet il y a qq temps. Mais a n'intresse peut tre pas tout le monde.

2) Chapitre III.d. Rutiliser une requte prpare pour gagner en performance. Un petit benchmark de perf (PDO/MYSQL) aurait t sympa.

Et encore merci, ce tuto manquait au palmars  ::ccool::

----------


## FMaz

Il faut savoir que l'article pourra tre amliorer, je note donc vos suggestions. ( En fait pas vraiment, ce serait mieux si vous n'effaciez pas vos rponses :p )

hornetbzz:

*Parler des singletons*: Pour quel usage exactement ? Le seul singleton qui me semble raisonnable d'adopter sans tomber dans la singletonnite aigue serait pour faire un connexion manager, mais c'est un peu hors du cadre de cet article (mais peut-tre pas d'un second volet)

*Benchmark*: Ouep, je vais y voir  ::): 


gene69:

*Trop de remerciements*: Il n'y en a pas tant que ca ? As part pour Guillaume, je vois pas trop quel remerciement j'ai fait dans l'article.

*Gestion des exceptions*: C'est hors du cadre de l'article, mais ca pourrait trs bien se joindre  un second volet en mme temps que de parler d'un connexion manager qui tend les classes PDO. Cet article s'adresse  l'explication de la base. Il se veux donc clair, pertinent pour une majorit des ca, et surtout direct et concis.

C'est donc un choix volontaire de ne pas en avoir fait un tutoriel "de ralisation" ou un guide sur les pratiques de dveloppement.  la limite, certaines personnes peuvent ne pas vouloir utiliser les exceptions dutout, tout comme j'ai dmontr que les requte prpare n'tait pas obligatoires...

*Pourquoi PDO si mysqli est plus "performant"*: J'aimerais quelques bench  ce sujet, mais sur la base, j'aurais tendance  rpondre simplement: Pourquoi C++ si l'assembleur est plus performant ? Pourquoi Java si C++ est plus performant ?

Si MySQLi fait bien le travail pour les applications actuelles: tant mieux. Mais le futur de PHP se dirige clairement vers PDO, vaux donc mieux s'y mettre  :;):  Par exemple, Doctrine est une sur-couche de PDO. Donc pour ceux qui souhaitent utiliser un ORM dans un projet, ca deviens essentiel.

*comment obtenir une trace sql avec PDO?* Tu peux me prciser ce que tu recherche concrtement ? (Pour moi une trace est une liste du chemin d'excution ayant men au point du "bug". XDebug permet d'avoir une trace de son code PHP. Mais dans le cas d'une requte, je vois mal la pertinence d'avoir une trace; il n'y a qu'une requte, puisque chaque requte est isole...)

----------


## FMaz

> J'ai remplac comme ceci :
> 
> 
> ```
> 
> ```
> 
> Il n'y a certes plus d'erreur, mais je ne suis pas en UTF-8 pour autant.



Je crois qu'avec PHP 5.3.0, c'est sans espoir.
As-tu essay ceci ?


```

```

?

----------


## hornetbzz

*Singleton*:

Je pensais en ralit  cet article vers lequel tu pourrais peut-tre faire un renvoi du genre "_aller plus loin_".

En fait a m'intresse  titre perso, car lors de ma phase "dcouverte" de la POO et PDO, j'tais tomb sur un bug PDO- un peu par hasard - qui m'avait t mis en vidence par Runcode, PetitBidon et AcoeurPerdu. Ce bug tait apparu justement en cherchant maladroitement  coder un singleton.

----------


## grunk

> pourquoi PDO si mysqli est plus performante aujourd'hui? J'en ai rien a faire d'une extension qui fonctionnera bien dans 5 ans pour mes dveloppements d'aujourd'hui


J'aurais aussi et surtout envie de dire qu'avec PDo tu as un interface uniformise. Effectivement si tu ne travail qu'avec des bases mysql l'intrt est moindre , mais par exemple j'ai plusieurs projet qui fonctionnent avec une base local et une base distante qui ne sont pas les mme (sqlite/mysql , mysql/mssql ...)
Avec PDO pas besoin de me souvenir des api sqlite_,mysql_ et mssql_ , je change juste mon constructeur et la suite est identique.

----------


## jpvincent

merci pour cet article, je n'avais encore jamais remarqu  quel point les fonctions mysql_* taient en phase d'abandon, mais il faut dire que je n'ai pas eu de projet avec mysql/PHP depuis longtemps

sur mon dernier projet je travaille avec oracle et pour faire ma classe de connexion  la base, je me suis pass de l'abstraction faite par Zend_Framework pour directement utiliser les fonction oci_*
J'ai pu gagner en rapidit et a m'a surtout permis d'identifier un bug de la version d'oci que PHP utilisait

en fait au dbut j'tais enthousiaste  propos de PDO pour abstraire la technologie utilise pour la base, mais en mme temps je n'ai jamais compris 2 choses :
- y a t il seulement des projets qui changent de base de donnes ?
- lorsque l'on change de base, la majorit des problmes vient des requtes qui ne sont plus toutes compatibles avec le nouveau moteur, et PDO n'y change rien. 

ce qui m'amne  cette question  laquelle ton article ne rpond pas : est ce que cela vaut le coup de (lgrement) ralentir tous les accs  la base, voir dans mon exprience de ramer pour trouver un bug, en prvision d'un changement de base de donnes qui n'arrivera au pire jamais, ou qui au mieux demandera normment d'effort sur l'ensemble de tout le projet ?

----------


## RunCodePhp

> Je crois qu'avec PHP 5.3.0, c'est sans espoir.
> As-tu essay ceci ?


C'est ainsi que j'ai fais depuis que j'utilise PDO, le problme n'est pas l.  :;): 

C'est juste par pure curiosit que j'ai remarqu ce dtail dans ton article, soit permettre de rajouter le charset directement en paramtre dans l'instanciation, chose que je ne savais pas, et me disant que a va me permettre d'conomiser 1 requte.
C'est dire que c'est franchement pas important.  ::D: 

Je te rejoins en tout cas sur le fait que ce serait peine perdue pour Php5.3.0, il y a un bug  ce niveau, je suis tomb sur rapport, et il a d tre corrig/fix dans les versions future.
Une affaire rgle, pas d'bol, il a fallut que a soit un bug on va dire.

Merci d'avoir pris le temps de rpondre en tout cas.  :;): 




Pour donn un peu un avis par rapport  quelque remarques qui ont t faites, je trouve qu'il aurait t tout de mme intressant de parler des Exceptions pour PDO, ceci pour plusieurs raisons.

- La 1re, c'est que les Exceptions fait partie prenante de PDO, il y a une classe ddie PDOException, au mme titre que la classe PDO elle mme et PDOStatement.
Ca ne me semble pas un dtail.

- Ensuite, cet article se veut, faire quelque part l'loge de PDO (disons c'est mon impression), donc d'inciter les codeurs  utiliser PDO plutt que les fonctions mysql_* (je rsume).

- La gestions des Exceptions est  mon sens un bon argument pour ne serait-ce dmontrer que PDO offre bel et bien d'autres possibilits, encore une de plus on va dire, voir une autre approche diffrente.
Ca sera peut tre une occasion aux codeurs amateurs (car je suppose que c'est en majorit les codeurs amateurs qui n'osent pas utiliser PDO)  se frotter aux Exceptions.
Disons que mme si ce n'est pas obligatoire, on se donnera la possibilit de le faire plus tard, et a plus facilement vu que la gestion des Exceptions est dj prsente nativement.

- Le petit hic, on va dire que les Exceptions n'est pas si simple, je doute que ce soit un mcanisme si vidant que a  comprendre.
Quelques exemples concret serait rellement un plus.
Ok, je comprends cependant que cela va  l'encontre d'un article qui se veut simple, direct et concis.
Peut alors rajouter quelques liens vers d'autres articles qui implmenterais a.


Pour ce qui est du choix du singleton, je ne suis pas certain qu'il faille en parler.
Le modle singleton, c'est du design patern, a n'a pas de rapport avec PDO  mon sens, c'est de la POO, en parler a pourrait laisser sous entendre que PDO devra tre implmenter comme singleton.
Mais bon, rien n'empche de mette un lien vers des solutions concrtes sur l'usage de PDO.


Un autre aspect, peut tre l'as tu remarqu.
Bon, on peu peut tre considrer a comme n'tant pas li  PDO, mais plutt  MySQL, ou  l'API.
N'empche que je trouve toujours aussi droutant (mais vraiment) un tel comportant.

Je m'explique, et c'est trs simple.
J'ai remarqu que le type de donne que retourne un fetch() ou fechAll() n'est pas du tout respect, que toutes les donnes sont considres comme des chaines de caractres, des string.

Si on ajoute un gettype() sur chaque donne retourne, c'est des string.  ::aie:: 
Pourtant, lorsque j'affiche les infos que retourne PDOStatement:getColumnMeta(N colonne), ce tableau contient entre autre un *pdo_type*, donc le type de donne du champ.
Si c'est un INT par exemple c'est 2 qui est retourn qui correspond  PDO..PARAM_INT.
Mais pourquoi donc PDO ne cast t-il pas cette fichue donne ?  ::mrgreen:: 

Bon, on va me dire que ce n'est peut tre pas son rle, et que ce serait  soit mme de s'appuyer sur ce fameux type ou autre pour le faire.
Ma faon de voir reste malgr tout l'inverse, que ce serait justement  PDO de caster ces valeurs selon le type de donnes, ou alors, que ce soit en option, dans le mme esprit que de dclarer si on souhaite une gestion des Exception ou pas.
Je me trompe peu tre, ce serait une mauvaise approche, mais le fait est l.  ::?: 

Voil un aspect qui de mon cot demeure toujours flou, incompris.  :8O: 
Que les choses soient clair aussi, je ne cherche pas de solution, ce serait m'loigner du sujet, on va dire qu' l'heure actuelle j'admets que c'est ainsi, je fais avec, mais que cet aspect pourrait faire l'objet d'un court passage sur les types de donnes avec PDO.
Voil, voil ...  :;):

----------


## grunk

> - y a t il seulement des projets qui changent de base de donnes ?


N'importe quel CMS  l'heure actuelle est compatible au minimum mysql/pgsql ce qu ifait dj deux bases et justifie l'utilisation de pdo ou de tout autres couche d'abstraction.




> - lorsque l'on change de base, la majorit des problmes vient des requtes qui ne sont plus toutes compatibles avec le nouveau moteur, et PDO n'y change rien.


Si tu cris du SQL standard y'a peut ou pas de chose  revoir.

----------


## FMaz

> La gestions des Exceptions est  mon sens un bon argument pour ne serait-ce dmontrer que PDO offre bel et bien d'autres possibilits, encore une de plus on va dire, voir une autre approche diffrente.
> Ca sera peut tre une occasion aux codeurs amateurs (car je suppose que c'est en majorit les codeurs amateurs qui n'osent pas utiliser PDO)  se frotter aux Exceptions.
> Disons que mme si ce n'est pas obligatoire, on se donnera la possibilit de le faire plus tard, et a plus facilement vu que la gestion des Exceptions est dj prsente nativement.
> 
> - Le petit hic, on va dire que les Exceptions n'est pas si simple, je doute que ce soit un mcanisme si vidant que a  comprendre.


Hum-hum...
Je n'avais pas vu la chose sous cet angle...
Mais c'est vrai qu'il y a un manque  combler  ce niveau.

Qui sait, si j'ai du temps libre (  ::roll::  ) ca pourrait tre un second article.

----------


## stealth35

y'a toujours le mode PDO::ERRMODE_WARNING, t'as mis le PDO::ERRMODE_EXCEPTION par dfaut mais tu fais aucun try...catch  :;):

----------


## FMaz

Ca peut sembler trange, mais c'est tout  fait volontaire de ma part. Cet article n'est pas un "tutorial  copier coller", qui explique et guide l'utilisateur vers une solution.

Il s'agit d'un article concret, qui se veux une base de comprhension. En somme, si je veux expliquer comment se connecter, je ne veux pas enfouir les lignes importantes sous du code qui n'est pas ncessairement li  l'explication. (J'ai souvent des clients qui m'arrivent avec du code qu'ils ont btement copi-coll de tutoriels et dont 50% de celui-ci est strictement inutile au projet. Au Qubec on dit souvent: "trop c'est comme pas assez.")

Donc il y a 2 buts  cet article:
- tre un premier contact avec PDO, et permettre  un dbutant de mieux comprendre les concepts derrire les futurs tutoriels qu'il lira.
- Faire raliser certains concepts  la base mme de PDO qui ne sont pas toujours bien expliqu  une personne ayant dj essay, ou utilisant dj PDO.

Donc en aucun cas cet article ne prtend tre un tutoriel du type "lisez-moi et convertissez vos projets vers PDO immdiatement aprs"  :;): 

Je n'ai pas abord les exceptions plus qu'il faut, car je pense que le sujet dpasse le cadre de cet article, et je prfrais consacrer un autre article bien distinct  ce sujet, qui est assez vaste quand mme. (Et lorsque cet article existera, je ferais un beau lien: promis !)

----------


## stealth35

> Je n'ai pas abord les exceptions plus qu'il faut, car je pense que le sujet dpasse le cadre de cet article, et je prfrais consacrer un autre article bien distinct  ce sujet, qui est assez vaste quand mme. (Et lorsque cet article existera, je ferais un beau lien: promis !)


Donc mettre le ERRMODE_WARNING pour la connexion serai plus logique  :;):

----------


## FMaz

Hum, tu me place face  un dilemme  :;):  :
- Si je configure ca en WARNING, c'est comme si je dcourageais l'utilisation des exceptions.
- Si je met des try-catch, je vais contre mon principe de simplicit...

Bon bon, et si j'accepte de mettre un try-catch pour la connexion, tu va en exiger pour tous les exemples qui suivent aussi ?  ::aie:: 

(Ngocier, toujours ngocier  ::ccool:: )

----------


## stealth35

> Hum, tu me place face  un dilemme  :
> - Si je configure ca en WARNING, c'est comme si je dcourageais l'utilisation des exceptions.
> - Si je met des try-catch, je vais contre mon principe de simplicit...
> 
> Bon bon, et si j'accepte de mettre un try-catch pour la connexion, tu va en exiger pour tous les exemples qui suivent aussi ? 
> 
> (Ngocier, toujours ngocier )


le try...catch pour la connexion est de toutes faons obligatoire, sinon impossible de savoir si c'est connecter, (a part avec if et instanseof PDO)

on va dire si on fait du procdurale c'est plus simple de d'utilis les exceptions, si on fait de l'objet on se tournera plus vers les exceptions, et rien n'empche dans une classe de faire set_exception_hanlder non plus  :;):

----------


## FMaz

Et maintenant ?
http://fmaz.developpez.com/tutoriels...re-pdo/#LIII.a

J'en ai profit pour faire 3 choses:
- Montrer comment faire une trace d'une erreur.
- Grer l'exception
- Ajouter la note sur le bug avec PHP 5.3.0

----------


## stealth35

la t'auras un *Fatal error*  chaque erreur de requte fausse

EDIT : t'as pas besoin de faire closeCursor() apres un fetchAll, c'est uniquement quand tu ne parcours pas tout les fetch (et y'a aussi fetchAll pour mysqli, mais uniquement quand il compil avec mysqlnd donc <= 5.3.0)

----------


## FMaz

Oui, je sais, c'est bien ce que j'ai dis plus haut ...
Mais je vais pas mettre des try-catch pour tout les exemples, ca serait pnible  la lecture.

Bon, je vais ajouter une note en mme temps que celle qui dit que je ne vais pas r-tablir une connexion pour tous les exemples.

----------


## stealth35

pourquoi tu voudrais r-tablir une connexion ?

----------


## FMaz

Regarde le dernier paragraphe de la section http://fmaz.developpez.com/tutoriels...re-pdo/#LIII.a

----------


## stealth35

ah oui ok, j'avais mal compris  :;):

----------


## Petibidon

J'ai pas vu d'exemple  propos de la mthode bindparam() dans ce tuto ?

Un exemple d'utilisation pratique pour des insertions massives :


```

```

----------


## FMaz

Je sais. Il ne m'a pas sembl utile de couvrir cette fonction qui s'avre ncssaire (obligatoire) que dans des cas trs particuli.

Merci cependant pour les prcisions dans les commentaires  ::):

----------


## stealth35

> Je sais. Il ne m'a pas sembl utile de couvrir cette fonction qui s'avre ncssaire (obligatoire) que dans des cas trs particuli.
> 
> Merci cependant pour les prcisions dans les commentaires


ouai pour du param_str et sans le param length ca sert pas a grand chose

----------


## Madfrix

> ouai pour du param_str et sans le param length ca sert pas a grand chose


Pour une question de scurit ou autre ?

Perso je mets jamais de param length, j'ai surement tords mais je dlgue la longueur de ma chaine  ma base ( varchar(50), varchar(100)...). A lui de tronquer !

Mais de toute manire, quand j'arrive  insrer en base, les contrles php ont dj t effectus en amont donc ce param ne me sers pas (du moins je pense)

----------


## stealth35

> Pour une question de scurit ou autre ?


non c'est plus dans le sens ou par dfaut tout est binder en str  :;):

----------


## Madfrix

oki je croyais que tu rebondissais sur l'exemple de Petitbidon qui utilisait PDO: ::P: ARAM_STR sans longueur  :;):

----------


## stealth35

> oki je croyais que tu rebondissais sur l'exemple de Petitbidon qui utilisait PDO:ARAM_STR sans longueur


oui, ducoup le bind sert a rien puisque tout est par defaut, ca aurai t plus parlant avec un PARAM_INT, ou avec le paramtre length  :;): 

sinon on peux aussi mettre les tableau ou des objets en paramtre



```

```

----------


## Madfrix

ou alors crer des objets personne avec stdclass ou une classe Personne de facon  ce que si un nom ou un prenom manque, il soit insrer NULL en table et qu'il y est pas d'erreurs de membre prenom/nom manquant mais c'est un autre sujet^^

----------


## stealth35

> ou alors crer des objets personne avec stdclass ou une classe Personne de facon  ce que si un nom ou un prenom manque, il soit insrer NULL en table et qu'il y est pas d'erreurs de membre prenom/nom manquant mais c'est un autre sujet^^


ouai, voir le top faire un FETCH_CLASS  :;): 
faudrais que je fasse un sujet sur les FETCH y'a plein de truc simpa, comme le class, into, lazy, func et surtout le group

----------


## Madfrix

Jamais utilis FETCH_CLASS alors je suis pas contre un tuto  ::D: 

Demain pour 10h c'est possible ?  ::mrgreen:: 

J'ai maintenant l'habitude d'utiliser le module Zend_Db pour le mapping et je dois dire que parfois on devient un peu fainant avec et qu'on oublie "les bases"  ::lol::

----------


## stealth35

> Jamais utilis FETCH_CLASS alors je suis pas contre un tuto 
> 
> Demain pour 10h c'est possible ? 
> 
> J'ai maintenant l'habitude d'utiliser le module Zend_Db pour le mapping et je dois dire que parfois on devient un peu fainant avec et qu'on oublie "les bases"


j'en avais fait un petit sur FETCH_GROUP :




> PDO offre une option intressante dans son fetchMode : PDO::FETCH_GROUP qui permet de grouper des entres par catgorie.
> 
> exemple :
> 
> Code php
> 
> 
> 
> 
> ...


il peux y avoir pas mal de combinaison pour les fetch, mais certaine ne marche qu'avec fetch(), d'autre qu'avec fetchAll et d'autre avec setFetchMode, y'en a plein mais beaucoup ne sont pas documents : http://www.php.net/manual/fr/pdo.constants.php

----------


## Madfrix

> plusieurs solutions :
> 
>     * Faire une requte DISTINCT sur les villes, et a chaque tour de boucle all chercher les personnes qui correspondes
>     * Crer un array temporaire et a chaque tour de boucle ajouter la personne ($tmp[$user['city']][] = $user) , et reboucler ensuite pour crer son tableau
>     * A chaque tour de boucle vrifier via un buffer si la ville a t mise et afficher les personnes, sinon afficher ville


Tu avais aussi la solution SQL mais le PDO::FETCH_GROUP n'avait plus d'intrt ^^



```

```

----------


## stealth35

tu dois retraiter quand mme, et faire un explode pour avoir ton tableau sachant que tu perds le nom de tes colonnes

----------


## Madfrix

On a rien sans rien ^^

par contre on fait qu'une seule requte

----------


## stealth35

> On a rien sans rien ^^
> 
> par contre on fait qu'une seule requte



tu fais qu'un requtes pour la solution 2 et 3, faut aussi trouver un sparateur qui ne sois pas dans les resultats aussi

----------


## Madfrix

je parle pour le cas de figure enonc, j'ai encore jamais vu de virgule dans le nom ou le prnom  :;): 

Mais c'est vrai que PDO::FETCH_GROUP est plus clean, reste  voir le temps de traitement sur grosses volumtries

----------


## stealth35

si tu veux un petit exemple simplifi avec FETCH_CLASS



```

```

on peux biensur le coupl FETCH_GROUP

on peu le faire direct aussi, mais la ca marche qu'avec setFetchMode


```

```

----------


## Madfrix

Merci l'ami, c'est simple et facilement comprhensible  ::):

----------


## stealth35

un autre exemple avec FETCH_CLASSTYPE, qui lui va prendre le nom de la premier colonne pour crer l'objet a la classe du mme nom. (en rajoutant la colonne rle, qui est sois admin sois guest


```

```

c'est pas trs percutant comme exemple mais ca montre mais ca pourrais servir dans le cas d'un UNION par exemple avec des tables diffrentes  :;):

----------


## FMaz

RunCodePHP m'a fait remarqu une importante erreur dans l'article. En effet,  plusieurs endroits (les joies du copier coller) j'avais ceci:


```

```

Prepare() retourne un PDOStatement, ce qui n'est pas le cas de la mthode execute().
J'ai donc corrig les exemples en question afin qu'il soient tel que:


```

```


Voil, dsol pour cette erreur, et encore merci  RunCodePHP

----------


## Invit

> Hum-hum...
> Je n'avais pas vu la chose sous cet angle...
> Mais c'est vrai qu'il y a un manque  combler  ce niveau.


Pour ma part, je constates que le TRY est utilis avec 
$bdd->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
chez les rares qui demandent le renvoie des exeptions. *lors de la connection*.

Alors encore plus rare sont ceux qui craient un TRY pour les requtes  ::?: 
Bien sur l'attribut est acquis a $bdd quand au retour d'exeptions,
mais encore faut'il un CATCH qui les reoivent.

Et la c'est le floux absolu, deux coles :
mettre les requtes dans le TRY de connection, donc un seul CATCH
Ou un TRY par requte ::roll::

----------


## FMaz

Maurisier:

Normalement les gens se font des gestionnaire de connection et d'erreur afin de centraliser la gestion des erreurs.

Par exemple, sur les gros projets, les erreurs de requtes seront forcment traites (loggu quelque part). Ainsi, on se doute bien que les dveloppeurs ne copie-collent pas le code d'ouverture et d'criture dans un fichier  chaque fois qu'ils ont une requte.

L'avantage de l'orient objet est que les classes PDO peuvent tre tendues.
De plus, si une exception n'est pas capture, elle est transmise  la fonction parent. Une erreur fatale d'uncatched exception arrivera uniquement si au terme de la rcursion il n'y a pas eu de capture.

En somme, pour tracer une image grossire, si tu as un index.php comme front-controlleur unique, il te suffirait de crer un gros try-catch et l'ensemble de ce qui est charg par ce fichier (c'est  dire tout ton code) sera captur.

----------


## Invit

*FMaz:*
Oui j'entends bien, mais il reste dsagrable d'incruster dans un seul TRY 
tout un code ... et perdu a la fin du php le Catch ...  ::oops:: 
Ton exemple a ce sujet est trop sommaire.
Tu vas te retrouver avec des includes etc ... pffff en plus c'est pas beau a lire.

----------


## FMaz

Heu ?? Je suis pas certain de comprendre ce que tu essaie d'exprimer. D'ailleurs de quel "exemple" parle-tu exactement ?
En ce qui me concerne, c'est un article sur PDO, pas sur la gestion des exceptions, et encore moins sur la faon de grer ses inclusions de fichiers. 

De plus si tu regarde les exemples du manuel PHP, tu verra qu'ils placent la connexion dans un try catch aussi, car la connexion n'utilise que les exceptions.

Aprs si tu ne veux pas utiliser les exceptions, tu n'es pas oblig. Mais on est en 2010 avec PHP 5 (pour ne pas dire 5.3), alors je ne vais pas recommander de grer ses erreurs en PHP 4... mais je n'ai rien contre ca, et l'article indique bien comment ne pas utiliser les exceptions.

----------


## Invit

*FMaz:*
Bien sur bien sur je comprends tout cela  :;): 
Je parlais de rcuprer les exeption sur les requtes PDO elles mmes,
bien sur pas sur du PHP  ::lol:: 
Mais c'est bon n'en parlons plus.  ::fem::

----------


## FMaz

Oui, je parlais de ca aussi.

Tu dois mettre en place un mcanisme de gestion des exceptions. Si c'est bien fait, c'est transparent. Dans mon cas j'ai un connexion manager qui instancie une classe tendue de PDO, qui elle est en lien avec un error manager.

De cette facon, j'instancie ma connexion, puis la gestion des erreurs et des statistiques est prises en charge en arrire plan sans que ca soit visible.

Mais c'est hors du spectre de l'article, j'en ai donc pas parl... pour le moment.

----------


## dorian53

> De plus, j'aimerais faire une mise en garde que l'utilisation des requtes prpare n'est pas une protection absolue contre les injections. Vous devez tout de mme valider vos entrs. (Donc si tu les a bien valide comme tu le dis, il ne devrait pas y avoir de problme).


Que faut-il faire alors pour s'assurer que la requte est protge ?

----------


## stealth35

> Envoy par *FMaz*
> De plus, j'aimerais faire une mise en garde que l'utilisation des requtes prpare n'est pas une protection absolue contre les injections. Vous devez tout de mme valider vos entrs. (Donc si tu les a bien valide comme tu le dis, il ne devrait pas y avoir de problme).


moi j'aimerai bien un exemple.

----------


## pc.bertineau

Je pense que ce qu'il veut dire, c'est que requte prpare n'est pas synonyme de protection contre les injections. Encore faut-il savoir les utiliser.

Je te renvoie vers un de tes posts ou tu expliques  quelqu'un comment les utiliser : http://www.developpez.net/forums/d10...e/#post5747039

a mon avis la remarque de FMaz vise  ne pas mettre de fausses certitudes dans l'esprit des dbutants notamment.

----------


## FMaz

Exactement.

L'article  t cris pour tre une base d'apprentissage saine  PDO. J'ai donc essay de casser certains "mythes". Par la suite, la lecture d'article plus pousse devrait tre facilit.

Quoi qu'il en soit, de ce que je sais, et sous toute rserve, l'utilisation d'une requte prpare et le passage des variables par les fonctions BIND est une protection suffisante concernant --seulement-- l'injection SQL.

Par contre, ca ne garanti pas la scurit de la donne pour les autres failles. Par exemple si le champs du nom d'utilisateur permet de stocker du code javascript, il est possible que ca permette d'exploiter d'autres failles qui ne sont pas spcifiquement lies  la base de donnes.

----------


## dorian53

Ok merci , a me rassure.

----------


## beegees

Bonjour,

Je trouve que c'est un bon tuto qui va beaucoup m'aider dans mon apprentissage.

Merci.

beegees

----------


## FMaz

> Bonjour,
> 
> Je trouve que c'est un bon tuto qui va beaucoup m'aider dans mon apprentissage.
> 
> Merci.
> 
> beegees



Me voil heureux alors ! Bonne route !

----------


## Asli Bilal

Bonjour,

Il me semble avoir vu une petite faute dans l'instanciation de la connexion.

```
$pdo = new PDO($connStr, 'Utilisateur', 'Mot de passe', $arrExtraParam);
```

au lieu de :

```
$pdo = new PDO($strConnection, 'Utilisateur', 'Mot de passe', $arrExtraParam);
```

Sinon merci pour ce tuto,
Bilal

----------


## redoran

> L'article  t cris pour tre une base d'apprentissage saine  PDO. J'ai donc essay de casser certains "mythes". Par la suite, la lecture d'article plus pousse devrait tre facilit.


toute a fait d'accord , personnellement j'ai appris pas mal de choses encore bravo +++  ::ccool:: 
juste faut voir le format pdf qui est un peut mal imprimer (page 8) .  ::roll::

----------


## Invit

Bonjour,
Je dcouvre bien tardivement ton TOPO sur PDO !
Un vrais bijoux, et pour cela mille bravos  ::fleur:: 

Je sais qu'il faut garder la "lgrete" a ton sujet, il n'empche que 
le mcanisme du PREPARE qui reste un pilier de PDO 
(pas obligatoir comme tu l'a soulign) mriterait quelques prcisions.

A ce sujet je te soumet une analyse dont tu fera le trie si bon te semble
pour l'incorporer si tu juges que cela n'alourdirait pas ton sujet.

____________________________________
Prpar ou pas, avec ou sans bindparam, au final chaque exec envoie en une seule fois la requte et les vraies variables au gestionnaire de base de donnes (par exemple MySql) a la diffrence du PREPARE SQL !

Dans un PREPARE (SQL par exemple) le gestionnaire reoit et analyse la requte et attend tout envoi de donnes sur le pointeur de l'instruction prpare.

Voil pour le prpare ...
______________________________________

Concernant "protection"  "injection" et "chappement"

l' injection doit tre vite par un contrle (de notre choix) 

Pour le reste "protection"  "chappement"

Juste un petit historique que vous connaissez bien sur:

Au dbut nous faisions avant un INSERT ou autre ... le fameux addslashes()
avec la douce contrainte de contrler l'tat d' activation de ou non des magic_quotes_gpc...

le rsultat .. plein d' antislashs et oblig a la relecture de faire un 
stripslashes()

Maintenant, les versions modernes de SQL / PHP ont cette superbe fonction
*mysql_real_escape_string*  qui fait EXACTEMENT la mme chose que PDO

A savoir doubler les ' et inscrire les caractres spciaux et accentus sur deux octets ! ce qui protge bien les donnes.

Ainsi la relecture est directe sans instructions !!
____________________________________

A++ et encore BRAVO !
Christele

----------


## sabotage

> Prpar ou pas, avec ou sans bindparam, au final chaque exec envoie en une seule fois la requte et les vraies variables au gestionnaire de base de donnes (par exemple MySql) a la diffrence du PREPARE SQL !


Pour Mysql (je ne sais pas pour les autres drivers), la prparation est par dfaut mul par soucis de compatibilit avec mysql < 5.1 mais il est possible d'utiliser la prparation du serveur mysql en changeant le paramtre ATTR_EMULATE_PREPARES.




> Maintenant, les versions modernes de SQL / PHP ont cette superbe fonction
> mysql_real_escape_string qui fait EXACTEMENT la mme chose que PDO


pas vraiment moderne : cette fonction existe depuis 11 ans et est maintenant class comme obsolte  ne plus utiliser.
Quand au fait qu'elle ferrait la mme chose que PDO je ne vois pas trop  quoi tu fais rfrence.



> A savoir doubler les ' et inscrire les caractres spciaux et accentus sur deux octets ! ce qui protge bien les donnes.


Les accents ne posent pas de problme dans les requtes et ne sont pas modifis par mysql_real_escape_string. Ca serait d'ailleurs bien gnant d'avoir des caractres multioctet dans un encodage simple octet non ?

----------


## Invit

> Pour Mysql (je ne sais pas pour les autres drivers), la prparation est par dfaut mul par soucis de compatibilit avec mysql < 5.1 mais il est possible d'utiliser la prparation du serveur mysql en changeant le paramtre ATTR_EMULATE_PREPARES.


Je n'ais pas contrl depuis longtemps, mais par dfault j'tais "True"  de base





> *mysql_real_escape_string()*
> pas vraiment moderne : cette fonction existe depuis 11 ans et est maintenant class comme obsolte  ne plus utiliser.
> Quand au fait qu'elle ferrait la mme chose que PDO je ne vois pas trop  quoi tu fais rfrence.


Je fais rfrence justement a la protection des donnes tels que je l'ais cris
plus bas.





> Les accents ne posent pas de problme dans les requtes et ne sont pas modifis par mysql_real_escape_string. Ca serait d'ailleurs bien gnant d'avoir des caractres multioctet dans un encodage simple octet non ?


Oui tu as raison Sabotage, mais c'est ce que m'indique mon diteur hexadcimal  ::oops:: 
Dans un fichier non UTF8 j'ais bien cela ... mais tu me mets le doute,
c'est peut-tre l'export en *.SQL qui provoque cela ???

Bref tu m'as mis un gros doute sur tout cela, je vais appronfondir ces trois points  ::oops:: 

A++ et merci
Christele

----------


## maildeseb

Je note une erreur dans le paragraphe nomm
*III.a. tablir une connexion avec PDO*

Le bloc try pour la connexion est crit ainsi :


```

```

or la variable de la ligne 3 (commente "//Ligne 3; Instancie la connexion"), $connStr, sort de nulle part. En fait, c'est la variable $strConnection qu'on devrait trouver  cet endroit.

La ligne marque 3 en commentaire devrait donc tre


```
$pdo = new PDO($strConnection, 'Utilisateur', 'Mot de passe', $arrExtraParam); //Ligne 3; Instancie la connexion
```

----------


## slack457

wow, super tuto !

Tout est si clair, j'ai beaucoup apprci de pouvoir comparer les codes MySQL et PDO, a aide normment  la comprhension.
J'avais du mal a vraiment comprendre solidement PDO avec les autres tutos que j'ai pu lire sur le WEB. Pas avec celui-ci !

Un grand merci !  :;): 

PS : bien vu maildeseb

----------


## ouldfella

merci pour l'article je me met  PDO mais y une chose que j'ai pas compris dans cet article 


```
$arrExtraParam = array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"); //Ligne 2
```

on a initialis la variable $arrExtraParam
mais jamais utilise, comment l'utiliser ?
peut tre comme a ?


```
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION, $arrExtraParam); //Ligne 4
```

----------


## sabotage

$arrExtraParam est utilise la ligne suivante :


```

```

http://fmaz.developpez.com/tutoriels...re-pdo/#LIII.a

----------


## Loup solitaire

Bonjour,

Je reconnais le sujet commence  dater un peux, mais j'ai quelques remarques  faire dessus :

*1.*Il me semble constater une erreur dans le paragraphe V.a :
Dans la partie sans prparation de la requte

```

```

La ligne 2 devrait s'crire comme a $statement = $pdo->query($query);. (Sauf erreur de ma part)
*2.*Toujours dans le paragraphe V.a La fonction rowCount() est utilis sur une requte de type SELECT.
Il est indiqu dans la documentation PHP que cette utilisation n'est pas recommande.
Peut-on donc vraiment utiliser cette fonction pour avoir le nombre de ligne slectionn ?

----------


## ABCIWEB

Bonjour,

Ce tuto date un peu, nanmoins c'est une bonne base pour l'introduction  pdo (notamment pour ceux qui viennent de mysql puisque les syntaxes sont compares au dbut) et il est encore assez visit c'est pourquoi je me permet quelques prcisions : 

1/ la connexion chapitre III.a 
2/ Explication du faux bug de la clause limit chapitre V.c 
3/ le nombre de paramtres dynamique chapitre IV.b.

1/ Depuis quelques annes on peut passer le charset dans la chaine de connexion ce qui vite d'ajouter une option de configuration.
*Plus important* il est trs recommand de dsactiver l'mulateur pdo de php pour laisser travailler celui du sgbdd. Si le sgbdd n'a pas de gestionnaire pdo alors celui de php se remettra en marche mme avec l'option dsactive. Le gros avantage est que le gestionnaire pdo du sgbdd est plus performant (car optimis pour le sgbdd) et surtout vous ne serez plus contraints de formater vos variables en entiers pour les passer dans la clause limit (cf chapitre V.c). En effet le gestionnaire interne du sgbdd saura retourner le bon type en fonction des besoins de la requte.

En suivant ces principes on peut donc faire une connexion de ce type :


```

```

Avec ce type de connexion, la problmatique du chapitre V.c disparat. Cela ouvre galement la perspective de pouvoir passer une clause limit dans un tableau pass en paramtre  la fonction execute(). Autrement ce ne serait pas possible car les lments des tableaux passs dans la fonction execute() sont formats en string.

Ce qui m'amne au chapitre IV.b qui est cod de manire un peu alambique (comme le confirme le commentaire  la fin du paragraphe).
On pourrait faire plus simplement :


```

```

Maintenant si je souhaite ajouter une clause limit galement dynamique :


```

```

Notez que si je n'avais pas dsactiv l'mulateur pdo de php dans les options de connexion, cette requte ne fonctionnerait pas.

----------


## FMaz

Bonjour  tous.

Merci pour vos commentaires constructif. Ce tutoriel tait mon premier (et seul ici je crois). Depuis sa publication, j'ai chang de carrire donc je n'ai pas t trs actif sur ce forum (pas dutout en fait). Donc par rapport  vos commentaires:

ABCIWEB:
- pour ce qui est de la mthode SGBDD, honntement je ne connais pas. Les choses ont peuvent avoir changes, mais j'ai probablement oubli depuis le temps.
- En ce qui concerne l'exemple des place holders dynamique, je ne cherchais pas  dmontrer la meilleure mthode, ni la plus compacte, ni la plus rapide. Mais la plus facile  comprendre. En ce sens, je trouve que l'exemple que j'ai propos est plus facile  suivre et  comprendre que le (probablement meilleur) code que tu prsente.

Loup Solitaire:
- semble avoir raison au sujet de la petite erreur, il faudrait que quelqu'un corrige $statement = $pdo->query(); -> $statement = $pdo->query($query);  -

maildeseb
- Mme chose, bien vu, il y a une erreur dans le code qui tabli la connexion.


Bref, je n'ai plus les outils de publication, ni les connaissances pour mettre  jour le tuto par rapport aux nouvelles pratiques ou aux nouvelles versions de PHP. Si quelqu'un est capable de reprendre la gouverne de ce tutoriel, j'offre mon accord  Developpez.net de le r-attritrer le tutorial  un auteur capable de faire les modifications ncssaires. Je souhaite seulement que mon nom demeure comme tant l'auteur original de l'article.

Ps.: Je recois encore les emails de notification...




Encore une fois merci  tous pour vos commentaires ! (Et dsol de ne pas pouvoir effectuer les corrections moi-mme  ::(:   )

----------


## Invit

> Bonjour  tous.
> 
> Merci pour vos commentaires constructif. Ce tutoriel tait mon premier (et seul ici je crois). Depuis sa publication, j'ai chang de carrire donc je n'ai pas t trs actif sur ce forum (pas dutout en fait). Donc par rapport  vos commentaires:
> 
> Bref, je n'ai plus les outils de publication, ni les connaissances pour mettre  jour le tuto par rapport aux nouvelles pratiques ou aux nouvelles versions de PHP. Si quelqu'un est capable de reprendre la gouverne de ce tutoriel, j'offre mon accord  Developpez.net de le r-attritrer le tutorial  un auteur capable de faire les modifications ncessaires. Je souhaite seulement que mon nom demeure comme tant l'auteur original de l'article.
> 
> Ps.: Je reois encore les emails de notification...
> Encore une fois merci  tous pour vos commentaires ! (Et dsol de ne pas pouvoir effectuer les corrections moi-mme   )


En fait PDO n'est pas Mysql !! tout vient de l !
Il y a en rsum : Mysql (Prim), Mysqli conserv et   PDO_Mysql qui a mon sens reste la roll's.
Regardes ceci http://php.net/manual/fr/mysqlinfo.api.choosing.php

Je ne peux pas me propos  reprendre ton article, mais a pourrait se faire  la rentre.
Amities

----------


## ABCIWEB

> En ce qui concerne l'exemple des place holders dynamique, je ne cherchais pas  dmontrer la meilleure mthode, ni la plus compacte, ni la plus rapide. Mais la plus facile  comprendre. En ce sens, je trouve que l'exemple que j'ai propos est plus facile  suivre et  comprendre que le (probablement meilleur) code que tu prsente.


C'est pas vraiment meilleur, c'est surtout plus pratique. Quand tu mentionnes  la fin du paragraphe IV.b. que "la perfection n'est pas de ce monde" c'est qu'effectivement le code devient un peu lourd avec des marqueurs dynamiques si l'on veut binder individuellement les variables. 

Tu ne pouvais gure faire mieux sauf en utilisant "array_fill" pour crer la chaine de marqueurs (mais a reste une amlioration anecdotique), mais ce que je voulais surtout dire est que dans le cas de marqueurs dynamiques le passage du tableau de variables dans le execute() est la voie la plus pratique et du coup le code devient plus fluide  ::):  Aprs on est bien d'accord que c'est pour optimiser le visuel et l'criture du code, sinon c'est pas les foreach en plus qui vont changer significativement les performances pures.

Pour le reste, l'histoire de dsactiver l'mulateur pdo de php est une information que je ne vois pas assez  mon sens et pourtant c'est super pratique et plus performant donc dommage de s'en priver. D'autant plus qu'aujourd'hui tous les sgbdd ont leur propre gestionnaire pdo. Mais bon  l'poque de l'criture du tuto cette info n'tait peut tre pas pertinente.

Pour conclure, je te remercie de ce tuto car c'est celui dont je me suis servi en premier quand j'ai voulu passer  pdo aprs une longue priode mysql puis mysqli. Je l'ai trouv trs bien fait, efficace, et il m'a permis d'acqurir rapidement de bonnes premires bases. Et c'est d'ailleurs parce que je continue  le recommander que j'ai voulu apporter ces quelques informations complmentaires pour l'actualiser  :;):

----------


## Gouyfre

Je suis dbutant en programmation et je n'aime pas suivre btement les tutos car le lendemain j'ai quasiment tout oubli! par contre le fait de comprendre le fonctionnement et les diffrences avec les autre mthodes me permettent de beaucoup mieux retenir les processus, de m'aider  trouver les erreurs que je fais, que du bon quoi!
C'est pour cela que je tiens  vous remercier pour le temps pass  crer cet article,  la pdagogie utilise, c'est beaucoup plus clair pour moi et me permettra de mieux comprendre mon code pour repousser encore plus mes connaissances!!!
Merci et bonne continuation!

----------

