ABSTRACTION PDO

Commentaire de neigedhiver le 04/01/2009 13:45:58

Salut,

Tu devrais préciser que la version de PHP requise est 5.3, parce que sinon, y'en a pas mal qui vont pas comprendre les messages d'erreurs alors qu'ils sont avec la dernière version stable ;)
C'est la première source que je vois qui nécessite PHP5.3 : ça fait plaisir, mais ça pourrait être intéressant de faire fonctionner ça sur PHP 5.2.x

J'ai pas regardé le code en détail (comme toujours... désolé... :/ ) mais avoir un commentaire comme ça de la part de WebDeb, c'est une belle performance. Donc rien que pour ça, chapeau !

@WebDeb : euh je ne te critique pas, hein, c'est juste que comme tu es exigeant (et c'est une qualité pour moi), il est rare que tu laisses un commentaire qui laisse penser que la source est parfaite... D'où la performance...

Et bonne année tout ça tout ça *=/:-)

Commentaire de dorian91 le 04/01/2009 15:57:14

Oups désolé j'ai oublie de retirer les namespaces. La source est mise à jour.
Merci pour vos commentaire ça fait plaisir.
Je suis en train de faire une petite mise a jour pour pouvooir lancer une action sur certaine méthode de pdo
Par exemple logger des requetes.
Je met la source a jour des que c'est fini

Commentaire de dorian91 le 04/01/2009 18:39:30

J'ai oublié de préciser que les nouvelles classes doivent etendre PdoManager et donc définir les méthodes abstraites.
Quand tu utilise la fatory il vérifie si la classe passé en paramètre etends la classe PdoManager

Commentaire de webdeb le 05/01/2009 10:04:56

@CodeFalse : concernant ta remarque au sujet de isset() vs array_key_exists(), je plussoie complètement. Une autre différence les sépare également que tu n'as pas mentionnée. isset() vérifie que la variable existe bien et qu'elle n'est pas nulle alors que array_key_exists() vérifie uniquement si la clé existe dans le tableau mais ce moque de savoir si sa valeur est nulle ou non.

Commentaire de dorian91 le 05/01/2009 12:40:49

Merci pour vos commetaires. Je ne connaissais pas les diférences de comportements et de performance entre isset et array_key_exists. Je vais devoir modifier tous mes codes ^^, j'utilise tout le temps array_key_exists je trouve ça plus jolie ^^. Je met a jour la source

Commentaire de codefalse le 05/01/2009 14:51:43 administrateur CS

@Dorian91 : Mais de rien ! :) c'est là pour ca !

Commentaire de dorian91 le 06/01/2009 00:18:40

La classe PdoManager est une classe abstraite qui définit 4 méthodes abstraites :

abstract protected function _getDsn();
abstract protected function _setConnectionEncoding();
abstract public function describe($sNameTable, $sSchema = null);
abstract public function listTable();

Si tu étend la classe PdoManager sans implémenter ces méthodes tu aurras une erreur comme avec les interfaces.

Commentaire de stailer le 06/01/2009 00:37:19

Mais c'est la que je comprends pas.. pourquoi faire ces verifs etc , alors que PHP via les interfaces les faits automatiquement ? C'est du code en plus avec ton "method_exists" et "get_class".

Enlève ce "if", mets une interface, ça ne sera que plus propre et avantageux pour le maintien et l'évolution de ta classe.

Commentaire de dorian91 le 06/01/2009 10:00:05

En gros la méthode :

/**
   * Mapping des fonction PDO
   *
   * @access public
   * @param string $sMethod
   * @param array $aArguments
   * @return mixed|boolean
   */
  public function __call($sMethod, $aArguments)
  {
    if( method_exists(get_class($this->_oPdoInstance), $sMethod) )
    {
      return call_user_func_array(array($this->_oPdoInstance, $sMethod), $aArguments);
    }
    
    return false;
  }

Me sert a mapper les méthodes PDO. Pour pouvoir faire par exemple $oPdoMysql->query()
Je fais un méthode existe pour tester si la méthode est présente dans Pdo si non je retourne false au lieu d'une erreur PHP
Le principale interet est que si je veux lancer certaine action sur des méthodes PDO je peux le faire dans la méthode __call
Un petit exemple :
je fais un $oPdoMysql->query('SELECT tata_yoyo FROM chapeau');
La méthode query va etre attrapé par __call et je souhaite logger toutes les requetes qui passent

public function __call($sMethod, $aArguments)
  {
    if( method_exists(get_class($this->_oPdoInstance), $sMethod) )
    {
      if( $sMethod == 'query' ) Logger::add($aArguments[0]);
      return call_user_func_array(array($this->_oPdoInstance, $sMethod), $aArguments);
    }
    
    return false;
  }

C'est un exemple vite fais hein
La méthode __call ne sert que pour PDO d'ailleur je fais un get_class($this->_oPdoInstance) qui est une instance de PDO
En gros c'est pour avoir a dispo toutes les méthodes de ma classe + celle de pdo dans une seule instance.
Bon je sais pas si c'est clair ^^ moi et les explications ca fais 2

Commentaire de linkinparkem le 01/02/2009 11:02:57

@Dorian91 : svp, j'ai pris ton script et je l'ai tester sur xampp avec comme version de php la version 5.3bêta2
mais au niveau du script "dao_factory.class.php" les namespaces sont reconnus mais dans les autres scripts il me retourne une errreur ds la 2éme ligne qui concerne l'utilisation des namespace si vous avez une solution à me partager je suis preneurs et si vous avez même une version sans les namespaces sa sera l'idéal et merci d'avance ! ;-)

Commentaire de dorian91 le 03/02/2009 21:12:43

Salut
Merci pour les commentaires.
linkinparkem >>> Pourrais tu me donner le message d'erreur que tu obtiens
Neigedhiver >>> Ah je ne savais pas pour le support des curseurs avec pdo mysql (pas l'habitude d'utiliser ces choses ^^). Faut que je me renseigne sur le fonctionnement des curseurs en SQL et je vois pour implementer cela.

Commentaire de neigedhiver le 03/02/2009 23:27:45

En fait, un curseur, c'est un peu (peut-être que je simplifie et que mes connaissances ne sont pas assez poussées) un itérateur, qui implémenterait aussi SeekableIterator.

En fait pour mes besoins à moi, j'ai implémenté cette fonctionnalité. En fait, j'ai plusieurs classes :
- DBStatement implements Countable
- DBStatementIterator extends DBStatement implements Iterator
- DBStatementCursor extends DBStatement implements Iterator, SeekableIterator
- DBStatementCursorNative extends DBStatementCursor
- DBStatementEmulation extends DBStatementCursor

DBStatement est en fait un proxy pour un objet PDOStatement (qui est passé en argument du constructeur). La méthode count() retourne simplement PDOStatement::rowCount()

DBStatementIterator fournit un itérateur très simplifié qui ne parcourt l'objet PDOStatement qu'une seule fois, du premier au dernier enregistrement (sans rewind). C'est la base de ce qu'on attend d'un itérateur : récupérer les résultats du premier au dernier.

DBStatementCursor est une classe abstraite qui définit les méthodes next() et seek()

DBStatementCursorNative utilise les curseurs PDO : c'est la classse la plus performante dans le sens où elle utilise pleinement les curseurs.

DBStatementCursorEmulation est, comme son nom l'indique, une émulation de curseur : pour cela, j'utilise fetchAll() et je parcours le tableau ensuite avec l'itérateur. C'est moins performant puisque tous les résultats sont récupérés avant d'être ensuite parcourus 1 à 1. C'est la contrepartie de l'émulation d'une fonctionnalité. Cette classe est un peu limitée puisqu'elle n'utilise pas toutes les possibilités des curseurs et ne permet que de parcourir dans un sens, dans l'autre, ou d'accéder à un offset donné.

Bien sûr, pour chaque, il reste possible de préciser le mode de récupération (FETCH_OBJ, FETCH_ASSOC, etc).

J'ai pensé publier ma classe, mais comme il y a la tienne, je ne sais pas si c'est utile... La tienne fait des choses que la mienne ne fait pas, notamment, je n'ai écrit aucune fonction utilitaire, contrairement à toi : je me suis longtemps interrogé sur la réelle utilité méthodes utilitaires (sic) dans un DAO... En fait, il est fort probable que ça soit vraiment intéressant dans certains cas (ça simplifie quand même un peu la vie du développeur, non ?). Bref, c'est pour moi un débat qu'il serait intéressant d'avoir (mais peut-être pas ici...)

Commentaire de neigedhiver le 04/02/2009 00:50:54

Rhaaaaaaaaaaaaaa !!!!!!!!!!!
Je comprends pas l'exemple 2 qu'on trouve sur la doc de rowCount() : http://fr.php.net/manual/fr/pdostatement.rowcount.php
Pourquoi ils utilisent fetchColumn() en parlant de ligne ? Y'a un truc qui m'a échappé ?
'tain, c'est pas génial quand même d'utiliser count(*)...
En même temps, en y réfléchissant... je me demande si avoir le nombre de lignes retournées est vraiment indispensable...
Quand on utilise les curseurs de PDO, on va pouvoir ne récupérer (facilement) que les résultats que l'on veut. Par exemple les 10 premiers (et moins s'il n'y en a pas autant). Si on veut savoir combien il y en a au total, il y a des chances qu'on soit en backend, et que donc, on puisse se permettre une requête select count(*) supplémentaire.
Avec MySQL, on peut utiliser SQL_CALC_FOUND_ROWS dans la requête SELECT si on utilise LIMIT, avec un petit select FOUND_ROWS() ensuite...
Bon mais j'avais pas fait gaffe à ça... :/

Bon ok, je vais mettre ma source. Ca fera que la 2560890334ème sur un DAO, ça fait rien... ^^
Je vais quand même m'assurer qu'elle est pas bugguée, sachant que je ne peux pas tester les curseurs de PDO, n'ayant pas de serveur Oracle sous la main (peut-être que Postgre les gère, maiis je n'ai pas non plus de serveur Postgre). Pis je dois corriger cette histoire de rowCount()...

Allez, bonne nuit les enfants !

Commentaire de neigedhiver le 04/02/2009 01:52:52

@Codefalse : Mmmmm... Ouais, mais avec un itérateur et une boucle foreach, t'as pas besoin de vérifier... Si résultat il y a, la boucle foreach est exécutée au moins une fois. Si pas de résultat, elle ne l'est pas. Le test n'est pas utile, puisque c'est foreach qui le fait en appelant la méthode valid() de l'itérateur...

Et puis je comprends pas : d'abord tu dis que rowCount() ne sert que pour les lignes affectées par DELETE, INSERT et UPDATE, puis là, tu me dis que tu t'en sers pour savoir si tu as des news à afficher... Tu les récupères pas avec une requête SELECT tes news ? Ou alors, je suis fatigué et trop vieux, et je devrais aller me coucher... ?

Commentaire de dorian91 le 04/02/2009 20:24:23

@Neige : Je suis aussi pour voir ta source. ^^
Pour les méthodes utilitaires je pense qu'elle sont très pratique du moins temps que les logiciels de bdd n'aurons pas une syntaxe et des fonctions sql identique (Je pense surtout a MySQL qui deroge a pas mal de règles).
De plus ce code fait partit d'un plus gros projet qui est un active record (presque fini ^^ en fait c'est un portage de l'active record ruby en php) donc je doit avoir des syntaxes identiques pour récupérer des données sur les tables etc...
Je suis en train de me documenter sur les curseurs et réfléchir a une méthode pour les implémenters.

Commentaire de neigedhiver le 04/02/2009 23:34:25

J'ai réfléchi un peu, et j'ai trouvé pourquoi je n'ai pas implémenté de méthode à mon DAO pour exécuter des tâches utilitaires.
Mes classes sont destinées à s'intégrer dans un framework. Si elles doivent permettre l'utilisation de n'importe quel SGBD grâce à PDO, elles n'ont pas vocation, dans une même application, à servir sur plusieurs SGBD différents. Contrairement à une application (forum, blog, cms) qui doit pouvoir (autant que possible) être utilisé avec soit MySQL, soit PostgreSQL ou autre (mais un seul à la fois), un framework est utilisé non pas par un utilisateur final, mais par un développeur... Et ça fait toute la différence.
Je sais pas si c'était hors sujet ou pas, bon...
Je retravaille un peu ma source, je la posterai j'espère avant vendredi (ça laisse que demain ça... ah ouais... mince alors...)

Commentaire de neigedhiver le 05/02/2009 00:43:22

Je suis à moitié d'accord avec toi. En fait, on pourrait sûrement en discuter pendant des mois sans parvenir à trancher, campant chacun sur notre position, sans avoir tort ni l'un ni l'autre. Je pense que c'est pas la même manière d'appréhender un projet.

Certains projets peuvent utiliser des SGBD différents... Oui, certes, sur de très gros projets, c'est tout à fait possible. Seulement pour accéder à un SGBD ou à un autre, on ne va pas nécessairement utiliser les mêmes scripts, même si ceux-ci utilisent les mêmes outils (ie le même framework).
Tout dépend où l'on fixe la limite de ce qu'on implémente. C'est un choix de la part du développeur (du framework) de fournir des outils plus ou moins complets (avec plus ou moins d'accessoires).
J'ai vu un framework MVC en PHP qui permet, semble-t-il de générer une interface d'admin sans quasiment écrire une ligne de code (je crois que c'est Jelix, mais je ne sais plus vraiment, et j'ai la flemme de chercher). Ils ont pris le parti de fournir un outil qui permet ceci. CodeIgniter, par exemple, non. C'est un choix. Aucun des deux n'est meilleur que l'autre. Voilà pourquoi nous risquons de ne pas être d'accord sans avoir tort pour autant ;)
Donc ok pour implémenter des utilitaires, je n'y vois aucun inconvénient, à la condition qu'on ne me reproche pas de ne pas en mettre dans mes classes (mais je peux toujours changer d'avis :)
En tout cas, j'apprécie particulièrement ces échanges que nous avons là : c'est vraiment intéressant et enrichissant (en tout cas pour moi, j'espère que c'est le cas pour vous aussi, et même pour les seuls lecteurs).

Bonne fin de soirée et bonne nuit :)

Commentaire de dorian91 le 05/02/2009 09:32:17

@Neige : Je ne te reprocherais pas de ne pas avoir implémenté ces méthodes ^^. En fait j'ai tellement l'habitude de faire des projets pour des clients qui veulent en faire le moins possible, je crois que ca déteint sur mes projets perso et j'oubli parfois que c'est pour des développeurs ^^. En tout cas c'est bien de voir aussi le point de vue et les méthodes des autres.
Pour PDO il tend à unifier l'accès aux BDD mais il y a tellement de différence que c'est pas gagné ^^

Commentaire de dorian91 le 05/02/2009 12:34:04

Oui symphony permet de faire ce genre de chose (d'ailleur c'est le framework qui se rapproche le plus du framework ruby).
J'avoue quand j'utilise un framework j'utilise rarement les méthodes utilitaires ^^.
Je vais tester ce soir le rowCount en php5.3 voir ce qu'il retourne. Peut être qu'ils auront uniformisé le retour.

Commentaire de neigedhiver le 05/02/2009 13:24:05

Entendons-nous bien : je n'ai jamais dit qu'un frammework ne devait pas permettr d'utiliser plusieurs SGBD. Je dis simplement que dans la plupart des cas, on n'utilise dans une application, qu'un seul SGBD. Oui, il peut arriver que de gros projets utilisent plusieurs SGBD SIMULTANEMENT. Mais je reste persuadé que c'est rare (surtout pour des projets en PHP...).
Ce que je voulais dire c'est que quand un développeur utilise un framework, celui-ci (le développeur) va développer pour le SGBD qu'il utilise, pas pour que ce soit compatible avec tous les SGBD de la planète. Contrairement à une application web comme un blog ou un forum qui doit pouvoir être utilisée sur n'importe quel SGBD.
Le public visé n'est pas le même : l'utilisateur final va vouloir installer (et que ça marche) avec le SGBD de son choix, le développeur qui utilise un framework va optimiser pour le SGBD qu'il utilise (et s'il en utilise plusieurs, il optimise pour que ça marche partout, c'est son affaire).

Commentaire de kiki2sirom le 06/02/2009 10:48:56

c'est marrant de voir qu'un code que, pour ma part, je qualifierai d'expert, soit mis en 'Débutant', alors que la plupart des scripts qui sont plus que limite, soit parfois (souvent ?) mis en 'Initié' voire 'Expert' ;) ça montre le comportement du programmeur.

En tout cas, je me fie aux autre personnes pour dire que c'est un joli code, même si je ne suis pas capable de le juger : c'est un trop haut niveau pour moi, un jour peut-être...
Par contre, je ne me permettrai pas de le noter

Commentaire de mikaweb88 le 22/03/2009 19:07:23

Bonsoir,

J'ai trouvé ta source très intéressante, j'ai décidé de changer la mienne en gardant certaines options mais en prenant ton système comme base de travail.
Je me posais en revanche une question, est-ce que l'utilisation de __call n'est-elle pas lourde à la longue ?
Une solution serait de re-déclarer toutes les fonctions, un peu redondants et chiant mais sûrement plus efficace, enfin je suis pas à 3 millièmes près :)

Je vais faire des tests et j'essaierai de donner un petit feedback par la suite.