+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 4 1234 DernièreDernière
Affichage des résultats 1 à 20 sur 73
  1. #1
    Membre expérimenté
    Avatar de FMaz
    Inscrit en
    mars 2005
    Messages
    649
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 649
    Points : 590
    Points
    590

    Par défaut Comprendre PDO

    Bonjour à tous.

    Je viens de compléter 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 créer un article qui va au fond des choses en me remémorant tout ce que j'ai pus trouver complexe à saisir par moi-même au début.

    J'ai aussi tenté de cibler les principales incompréhensions que j'ai constaté sur le forum, et d'étayer des réponses les plus simples possible. Il s'agit donc d'un article de niveau débutant/intermédiaire.


    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 !

  2. #2
    Modérateur
    Avatar de sabotage
    Homme Profil pro
    Inscrit en
    juillet 2005
    Messages
    21 574
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juillet 2005
    Messages : 21 574
    Points : 31 437
    Points
    31 437

    Par défaut

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

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

  3. #3
    Membre expérimenté
    Avatar de FMaz
    Inscrit en
    mars 2005
    Messages
    649
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 649
    Points : 590
    Points
    590

    Par défaut

    Merci pour la coquille, c'est déjà corrigé

    Et ouais, c'est aussi ce que je me disais... En fait j'ai constaté que beaucoup de gens ne comprennent même pas ce qu'est une requête préparée, et qu'ils pensent que c'est une particularité de PDO...

    Et que d'autre pense que les requêtes préparés sont "l'unique" facon de faire une requête avec PDO: et que c'est beaucoup plus long qu'un mysql_query().

    Alors voilà, je voulais abattre ces quelques préjugés trop souvent mal expliqués.

  4. #4
    Membre émérite

    Profil pro
    Inscrit en
    juin 2004
    Messages
    782
    Détails du profil
    Informations personnelles :
    Âge : 30
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : juin 2004
    Messages : 782
    Points : 819
    Points
    819

    Par défaut

    Bonjour,

    J'utilise PDO depuis longtemps et je trouve votre article bien rédigé, 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 requêtes préparées sans les fonctions "bind" mais en passant directement un tableau de valeurs à la requête préparée :

    Code :
    1
    2
    3
    4
    5
    $prep = $db->prepare('INSERT INTO table (champ1, champ2, ..., champN) VALUES (:champ1, :champ2, ..., :champN);');
     
    $values = array(':champ1' => $value1, ':champ2' => $value2, ..., ':champN' => $valueN);
     
    $prep->execute->($values);
    Je me suis auparavant assurer du bon type des valeurs passées en paramètre. Mais je me demande si cette utilisation protège des injections SQL ?
    • Mon blog PHP : http://blog.alterphp.com
    • "Peace cannot be kept by force, it can only be achieved by Understanding" -- Albert Einstein

  5. #5
    Membre Expert
    Avatar de Doksuri
    Développeur Web
    Inscrit en
    juin 2006
    Messages
    1 289
    Détails du profil
    Informations personnelles :
    Âge : 44

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : juin 2006
    Messages : 1 289
    Points : 1 636
    Points
    1 636

    Par défaut

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

    La forme des pyramides prouve que l'Homme a toujours tendance a en faire de moins en moins.

    N'oubliez pas le Le tag resolu.

    Need_!

  6. #6
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut

    Salut

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

    J'en ai donc même terminé que je me suis empressé d'essayer cette ligne :
    Code :
    $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.

    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 même 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'idée du comment exploiter cette technique, actuellement j'effectue un PDO::exec('SET NAMES utf8').
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  7. #7
    Membre expérimenté
    Avatar de FMaz
    Inscrit en
    mars 2005
    Messages
    649
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 649
    Points : 590
    Points
    590

    Par défaut

    J'en ai donc même terminé que je me suis empressé d'essayer cette ligne :
    Code :
    1
    2
    3
     
    $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.
    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 entière: comme valeur, on peut mettre "SET NAMES utf8" ou l'entier 1002, ca reviend au même.

    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 requêtes préparées sans les fonctions "bind" mais en passant directement un tableau de valeurs à la requête préparée :

    Code :
    1
    2
    3
    4
    5
    6
     
    $prep = $db->prepare('INSERT INTO table (champ1, champ2, ..., champN) VALUES (:champ1, :champ2, ..., :champN);');
     
    $values = array(':champ1' => $value1, ':champ2' => $value2, ..., ':champN' => $valueN);
     
    $prep->execute->($values);
    Hum, je suis un peu hésitant. La pratique est tout à fait légitime, et il n'y a rien de mal à ne pas utiliser les méthodes de binding. Cependant, pour être honnête, je ne sais pas trop.

    Mais si tu ne mentionne rien, je crois (à valider) que par défaut 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 requêtes préparée n'est pas une protection absolue contre les injections. Vous devez tout de même valider vos entrés. (Donc si tu les a bien validée comme tu le dis, il ne devrait pas y avoir de problème).

  8. #8
    Expert Confirmé Sénior

    Inscrit en
    septembre 2010
    Messages
    7 957
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 7 957
    Points : 10 638
    Points
    10 638

    Par défaut

    le bind ca sert surtout avec FETCH_BOUND.

  9. #9
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut

    Note au passage concernant le fait que PHP exige des valeur entière: comme valeur, on peut mettre "SET NAMES utf8" ou l'entier 1002, ca reviend au même.
    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 :
    Code :
    1
    2
     
    $arrExtraParam = array(1002 => 'SET NAMES utf8');
    Il n'y a certes plus d'erreur, mais je ne suis pas en UTF-8 pour autant.

    Bon, si tu as une idée, 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é.

    Merci et excellent article encore une fois.
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  10. #10
    Membre Expert
    Avatar de gene69
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    1 633
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 633
    Points : 2 122
    Points
    2 122

    Par défaut

    bonjour

    quatres observations:
    • les remerciements dans le texte, c'est pénible à lire, à la fin, c'est bien.
    • un argument plus détaillé 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 très bien s'occuper de protéger les données de façon aussi efficace. à part alléger 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 développements d'aujourd'hui.
    • comment obtenir une trace sql avec PDO? ça fait parti des préalables sur lequel je ne suis pas prêt à transiger. J'ai besoin d'une trace sql au niveau applicatif, mes bases ne voient généralement qu'un seul utilisateur, or il y en a plein dans la vraie vie. or jusqu'à présent, la classe d'accès aux données est un terrain stratégique pour espionner l'utilisateur.


    l'article est clair et c'est un bon travail, merci.
    PHP fait nativement la validation d'adresse électronique .
    Celui qui a inventé mysql_connect(...) or die() est déjà mort plusieurs fois.
    Soyez moderne: mysqli_connect() or throw Exception(mysqli_connect_error());

    PHP: un problème ? décrivez le avec ceci.

    Utilisez le bouton résolu!

  11. #11
    Membre chevronné
    Avatar de hornetbzz
    Homme Profil pro
    Directeur commercial
    Inscrit en
    octobre 2009
    Messages
    482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France

    Informations professionnelles :
    Activité : Directeur commercial

    Informations forums :
    Inscription : octobre 2009
    Messages : 482
    Points : 741
    Points
    741

    Par défaut

    Bravo, vraiment très bien, complet, très facile à lire et à comprendre, même pour un noob comme moi.

    L'intérêt de PDO est expliqué objectivement, ça laisse le choix au lecteur en connaissance de cause.

    La "passerelle" avec mysql est bien expliquée 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 galérer avec ce sujet il y a qq temps. Mais ça n'intéresse peut être pas tout le monde.

    2) Chapitre III.d. Réutiliser une requête préparée pour gagner en performance. Un petit benchmark de perf (PDO/MYSQL) aurait été sympa.

    Et encore merci, ce tuto manquait au palmarès

  12. #12
    Membre expérimenté
    Avatar de FMaz
    Inscrit en
    mars 2005
    Messages
    649
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 649
    Points : 590
    Points
    590

    Par défaut

    Il faut savoir que l'article pourra être améliorer, je note donc vos suggestions. ( En fait pas vraiment, ce serait mieux si vous n'effaciez pas vos réponses :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 très bien se joindre à un second volet en même 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 réalisation" ou un guide sur les pratiques de développement. À la limite, certaines personnes peuvent ne pas vouloir utiliser les exceptions dutout, tout comme j'ai démontré que les requête préparée n'était pas obligatoires...

    Pourquoi PDO si mysqli est plus "performant": J'aimerais quelques bench à ce sujet, mais sur la base, j'aurais tendance à répondre 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 préciser ce que tu recherche concrètement ? (Pour moi une trace est une liste du chemin d'exécution ayant mené au point du "bug". XDebug permet d'avoir une trace de son code PHP. Mais dans le cas d'une requête, je vois mal la pertinence d'avoir une trace; il n'y a qu'une requête, puisque chaque requête est isolée...)

  13. #13
    Membre expérimenté
    Avatar de FMaz
    Inscrit en
    mars 2005
    Messages
    649
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 649
    Points : 590
    Points
    590

    Par défaut

    Citation Envoyé par RunCodePhp Voir le message
    J'ai remplacé comme ceci :
    Code :
    1
    2
     
    $arrExtraParam = array(1002 => 'SET NAMES utf8');
    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 ?
    Code :
    1
    2
     
    $db->query("SET NAMES 'utf8'");
    ?

  14. #14
    Membre chevronné
    Avatar de hornetbzz
    Homme Profil pro
    Directeur commercial
    Inscrit en
    octobre 2009
    Messages
    482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France

    Informations professionnelles :
    Activité : Directeur commercial

    Informations forums :
    Inscription : octobre 2009
    Messages : 482
    Points : 741
    Points
    741

    Par défaut

    Singleton:

    Je pensais en réalité à cet article vers lequel tu pourrais peut-être faire un renvoi du genre "aller plus loin".

    En fait ça m'intéresse à titre perso, car lors de ma phase "découverte" 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.

  15. #15
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 187
    Points : 7 646
    Points
    7 646

    Par défaut

    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 développements d'aujourd'hui
    J'aurais aussi et surtout envie de dire qu'avec PDo tu as un interface uniformisée. Effectivement si tu ne travail qu'avec des bases mysql l'intérêt est moindre , mais par exemple j'ai plusieurs projet qui fonctionnent avec une base local et une base distante qui ne sont pas les même (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.
    Pry Framework php5

  16. #16
    Membre chevronné

    Inscrit en
    février 2010
    Messages
    120
    Détails du profil
    Informations forums :
    Inscription : février 2010
    Messages : 120
    Points : 760
    Points
    760

    Par défaut

    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 début j'étais enthousiaste à propos de PDO pour abstraire la technologie utilisée pour la base, mais en même temps je n'ai jamais compris 2 choses :
    - y a t il seulement des projets qui changent de base de données ?
    - lorsque l'on change de base, la majorité des problèmes vient des requêtes qui ne sont plus toutes compatibles avec le nouveau moteur, et PDO n'y change rien.

    ce qui m'amène à cette question à laquelle ton article ne répond pas : est ce que cela vaut le coup de (légèrement) ralentir tous les accès à la base, voir dans mon expérience de ramer pour trouver un bug, en prévision d'un changement de base de données qui n'arrivera au pire jamais, ou qui au mieux demandera énormément d'effort sur l'ensemble de tout le projet ?

  17. #17
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut

    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 problème n'est pas là.

    C'est juste par pure curiosité que j'ai remarqué ce détail dans ton article, soit permettre de rajouter le charset directement en paramètre dans l'instanciation, chose que je ne savais pas, et me disant que ça va me permettre d'économiser 1 requête.
    C'est dire que c'est franchement pas important.

    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 réglée, pas d'bol, il a fallut que ça soit un bug on va dire.

    Merci d'avoir pris le temps de répondre 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 même intéressant de parler des Exceptions pour PDO, ceci pour plusieurs raisons.

    - La 1ère, c'est que les Exceptions fait partie prenante de PDO, il y a une classe dédiée PDOException, au même titre que la classe PDO elle même et PDOStatement.
    Ca ne me semble pas un détail.

    - Ensuite, cet article se veut, faire quelque part l'éloge de PDO (disons c'est mon impression), donc d'inciter les codeurs à utiliser PDO plutôt que les fonctions mysql_* (je résume).

    - La gestions des Exceptions est à mon sens un bon argument pour ne serait-ce démontrer que PDO offre bel et bien d'autres possibilités, encore une de plus on va dire, voir une autre approche différente.
    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 même 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 déjà présente nativement.

    - Le petit hic, on va dire que les Exceptions n'est pas si simple, je doute que ce soit un mécanisme si évidant que ça à comprendre.
    Quelques exemples concret serait réellement 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 implémenterais ça.


    Pour ce qui est du choix du singleton, je ne suis pas certain qu'il faille en parler.
    Le modèle 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 implémenter comme singleton.
    Mais bon, rien n'empêche de mette un lien vers des solutions concrètes sur l'usage de PDO.


    Un autre aspect, peut être l'as tu remarqué.
    Bon, on peu peut être considérer ça comme n'étant pas lié à PDO, mais plutôt à MySQL, ou à l'API.
    N'empêche que je trouve toujours aussi déroutant (mais vraiment) un tel comportant.

    Je m'explique, et c'est très simple.
    J'ai remarqué que le type de donnée que retourne un fetch() ou fechAll() n'est pas du tout respecté, que toutes les données sont considérées comme des chaines de caractères, des string.

    Si on ajoute un gettype() sur chaque donnée retournée, c'est des string.
    Pourtant, lorsque j'affiche les infos que retourne PDOStatement:getColumnMeta(N° colonne), ce tableau contient entre autre un pdo_type, donc le type de donnée 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 donnée ?

    Bon, on va me dire que ce n'est peut être pas son rôle, et que ce serait à soit même de s'appuyer sur ce fameux type ou autre pour le faire.
    Ma façon de voir reste malgré tout l'inverse, que ce serait justement à PDO de caster ces valeurs selon le type de données, ou alors, que ce soit en option, dans le même esprit que de déclarer 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.
    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 données avec PDO.
    Voilà, voilà ...
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  18. #18
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 187
    Points : 7 646
    Points
    7 646

    Par défaut

    - y a t il seulement des projets qui changent de base de données ?
    N'importe quel CMS à l'heure actuelle est compatible au minimum mysql/pgsql ce qu ifait déjà deux bases et justifie l'utilisation de pdo ou de tout autres couche d'abstraction.

    - lorsque l'on change de base, la majorité des problèmes vient des requêtes 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.
    Pry Framework php5

  19. #19
    Membre expérimenté
    Avatar de FMaz
    Inscrit en
    mars 2005
    Messages
    649
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 649
    Points : 590
    Points
    590

    Par défaut

    La gestions des Exceptions est à mon sens un bon argument pour ne serait-ce démontrer que PDO offre bel et bien d'autres possibilités, encore une de plus on va dire, voir une autre approche différente.
    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 même 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 déjà présente nativement.

    - Le petit hic, on va dire que les Exceptions n'est pas si simple, je doute que ce soit un mécanisme 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 ( ) ca pourrait être un second article.

  20. #20
    Expert Confirmé Sénior

    Inscrit en
    septembre 2010
    Messages
    7 957
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 7 957
    Points : 10 638
    Points
    10 638

    Par défaut

    y'a toujours le mode PDO::ERRMODE_WARNING, t'as mis le PDO::ERRMODE_EXCEPTION par défaut mais tu fais aucun try...catch

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •