Journal PMO v 0.07 déjà

Posté par  (site Web personnel) .
Étiquettes : aucune
0
29
juil.
2007
Cher journal,

La v0.06 à peine publiée, une nouvelle version 0.07 de PMO vient de sortir. Je vous invite à faire des tests dès maintenant: Celle-ci intègre des améliorations assez significatives pour justifier l'existence de ce journal.

Un article qui décrit les nouveautés, et les benchs de cette v 0.07
http://pmo.developpez.com/versions/0.07/

L'url vers le manuel:
http://pmo.developpez.com/manuel/

Le site officiel:
http://pmo.developpez.com/
  • # Pour ceux qui ne saurait pas ...

    Posté par  (site Web personnel) . Évalué à 10.

    ... PMO est l'acronyme de "PhpMyObject", un Mapper de bases de données qui transforme les résultats de requêtes SQL en objets (ORM) (c'est donc écrit en PHP).

    C'est plus clair comme çà, non ? Ou la description était volontairement omise pour augmenter le nombre de hits sur la page ? ;-)
  • # Mmmm, voyons voir...

    Posté par  (site Web personnel) . Évalué à 4.

    Deux coups de clickouille, et j'arrive sur http://pmo.developpez.com/introduction/ où je peux lire cette remarquable précision: Du fait du fonctionnement de PMO, il faut utiliser des SELECT *, et non des SELECT sur un nom de colonne défini.

    C'est encore une PHPèterie salement gorête, quoi...

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: Mmmm, voyons voir...

      Posté par  . Évalué à 2.

      Voyons voir l'exemple de code qui donne une idée de l'API :


      $controler = new MyControler();
      $map = $controler->queryControler("SELECT * FROM utilisateur;");
      $object = $map->getObjectByValue("utilisateur", "login", "ancienlogin");
      $object->setAttribute('login','nouveaulogin');
      $controler->commitControler($object->getId());


      Pourquoi cette classe MyControler ? Est-ce qu'on ne peut pas encapsuler ça dans l'objet qui représente la donnée ? (btw controller prends deux L)

      Ensuite on doit taper une requête SQL pour simplement récupérer tous les enregistrements !? On peut pas éviter ça ? C'est censé être un ORM quand même. Qu'on permette l'utilisation de SQL pour des clauses d'agrégats ou des appels de procédures stockées par exemple, c'est bien, mais pour juste faire ça, je ne veux pas taper de SQL.

      Ensuite si je comprends bien le getObjectByValue va récupérer un enregistrement donné d'après la colonne login ? Pourquoi avoir chargé tous les utilisateurs alors ? SI j'ai 10 000 utilisateurs, on va tous les les récupérer depuis la bdd à chaque fois que je veux modifier un login, construire une structure de données puis filtrer les résultats ?

      Ensuite on fait la modification du l'attribut, ne peut-on pas avoir une syntaxe plus légère du genre $object->setLogin('nouveaulogin');

      Enfin le commit, et cette fameuse classe MyController dont je ne vois pas l'utilité en tant qu'utilisateur de ta lib. Et en plus je dois lui passer un id, alors qu'on sait déjà sur quel objet on travaille. Que ce controller te soit utile en interne OK, mais moi je ne veux pas m'en préoccuper, je veux juste mettre à jour un login.

      Voici à quoi pourrait ressembler l'API :


      $user = Utilisateur::getByLogin("ancienLogin");
      $user->setLogin("nouveaulogin");
      $user->commit();


      Sinon faire son auto-promotion dans Wikipedia je suis pas sur que ce soit de très bon goût ;)
      • [^] # Re: Mmmm, voyons voir...

        Posté par  (site Web personnel) . Évalué à 2.

        Impossible de répondre à ton post. Je ne sais pas pourquoi, le site refuse mon commentaire.

        la réponse dans un fichier texte ici:
        http://code34.girafon.org/reponse.txt
        • [^] # Re: Mmmm, voyons voir...

          Posté par  (site Web personnel) . Évalué à 1.

          Le code que tu cites est obsolète. La documentation "introduction" décrit le
          fonctionnement des versions antérieures. Le controler a évolué.

          Tu peux te référer au manuel qui est à jour:
          http://pmo.developpez.com/manuel/

          Pour répondre à ta question concernant SQL

          PMO tout comme PDO n'est pas la pour se substituer au langage SQL. PMO se
          concentre donc sur son rôle crée une couche d'abstraction objet entre le sgbd,
          et l'application.

          La méthode getObjectByValue peut récupérer un Objet (et non enregistrement car
          il embarque des méthodes) en fonction de l'attribut que tu désignes en
          paramètre. Ca peut être login si t 'as une table utilisateur avec une colonne
          login, tout comme ça peut être nomproduit si t'as une table produit, ou même
          age si t'as une table personne etc ... PMO découvre le schéma de tes tables
          dynamiquement, tu as donc des méthodes génériques.

          Le nombre d'objets que tu crées en mémoire, dépend de l'optimisation de ta
          requête. Si tu as une table avec 10000 enregistrements et que tu fais un
          select * sans critère forcément tu auras un nombre d'objets ultra importants.
          Et c'est clairement pas une bonne idée, si tu veux juste modifier un login ..

          Par contre si tu fais un select * from utilisateur where login="toto"; t'auras
          qu'un seul objet à manipuler ;) Les contraintes sont les même qu'avec un
          mysql_fetch_row hormis que tu manipules des objets.

          Pour le nommage setLogin, non étant donné que cette méthode est spécialisé à
          une colonne login, alor que setAttribute te permet de manipuler n'importe
          quelle colonne.

          Pour le $user->commit(), cela fait justement parti des dernières évolutions
          comme $user->delete();

          Si t'es vraiment interressé pour soumettre des évolutions, n'hésite pas à me
          contacter sur mon mail perso, ou sur la liste de diffusion google du projet.
          Jusqu'à maintenant j'ai essayé d'implémenter tout ce qu'on m'a soumis.
          • [^] # Re: Mmmm, voyons voir...

            Posté par  (site Web personnel) . Évalué à 1.

            J'ai aussi réussi à poster ce commentaire.
          • [^] # Re: Mmmm, voyons voir...

            Posté par  . Évalué à 1.


            Le code que tu cites est obsolète.

            Le code que j'ai cite provient du lien que tu as donne et que tu viens de mettre a jour en vitesse.


            PMO découvre le schéma de tes tables
            dynamiquement, tu as donc des méthodes génériques.

            Si on decouvre le shema, pourquoi ne pas creer dynamiquement des methodes specifiques ? D'ailleurs, quel est l'interet de cette decouverte de schema puisqu'on fournit les informations de shema a tes methodes generiques lorsqu'on les appelle ? Ce que je propose, c'est que lorsque pmo decouvre un champ login, il ajoute les methodes setLogin et getLogin, si le champ s'appelle age, il cree setAge et getAge et ainsi de suite...

            Sinon, je ne comprends pas l'interet de getObjectByValue puisqu'on doit de toute facon passer les criteres de selection a la requete SQL.
            • [^] # Re: Mmmm, voyons voir...

              Posté par  (site Web personnel) . Évalué à 1.

              J'ai pas mis à jour le lien en vitesse comme ça, j'ai retiré le lien qui pointait vers l'article obsolète pour que d'autres personnes ne soit pas orienté vers des docs anciennes comme tu l'as été.

              J'ai bien compris alpage ce que tu souhaitais. Depuis hier, soir on manipule directement les objets de cette façon:

              $object->login="toto";

              echo($object->login); // affiche toto

              j'ai implémenté les magiques qui dérrière font appel à setAttribute et getAttribute

              getObjectByValue sert à manipuler ta map d'objet

              Tu auras peut etre besoin de récupérer 100 objets et ensuite envie de les manipuler de façon non séquentielle.
              • [^] # Re: Mmmm, voyons voir...

                Posté par  . Évalué à 2.

                Je pense que ce que alpage te suggère, c'est tout simplement de mettre en oeuvre des design patterns pour ORM connus et éprouvés, plutôt qu'inventer le tient au hasard (et découvrir plus tard, lorsque tu sera tenu d'assurer une rétro-compatibilité, les limitations).

                Un exemple de motif de conception en vogue en ce moment : http://fr.wikipedia.org/wiki/Active_record_%28motif_de_conce(...)

                Déjà plusieurs fois implémenté en PHP, par exemple ici : http://phplens.com/lens/adodb/docs-active-record.htm
                C'est un bon exemple : John Lim a une remarquable expérience en la matière, tu peut t'en inspirer, et peut-être aussi utiliser sa bibliothèque ADOdb pour bénéficier d'une abstraction sur l'accès au moteur SGBD, donc d'une meilleure portabilité (parce que MySQL, c'est bien, mais il existe d'autres morteurs de bados (comment ça, "sqlite roxor" ? :P)).
                • [^] # Re: Mmmm, voyons voir...

                  Posté par  (site Web personnel) . Évalué à 1.

                  Le design pattern de pmo est documenté à travers les manuels, et les vidéos. Il y a aussi un diagramme de classe de la v0.06 sur la liste de diffusion (obsolète) mais qui donne une bonne vision de l'archi.

                  IL FAUT LIRE LES DOCS + les PHPDOCS dans l'archive , ça m'évite aussi de reexpliquer, 50 fois la meme chose. PMO implémente par exemple active record, et fait même plus que cela car il permet d'utiliser le polymorphisme, ou des maps ;)

                  PMO est plus souple que ADOdb (si tu ne comprends pas pourquoi, je t'invite à tester les 2), et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.

                  PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql ...
        • [^] # Re: Mmmm, voyons voir...

          Posté par  (site Web personnel) . Évalué à 4.

          PMO découvre le schéma de tes tables
          dynamiquement, tu as donc des méthodes génériques.


          Donc, à chaque page servie, PMO doit réapprendre ce qu'il à découvert quatre secondes plus tôt ?

          Si tu as une table avec 10000 enregistrements et que tu fais un select * sans critère forcément tu auras un nombre d'objets ultra importants.

          10000 lignes, c'est une petite table, très petite même.

          Les contraintes sont les même qu'avec un mysql_fetch_row hormis que tu manipules des objets.

          Sauf que le mysql_fetch_row, c'est juste de la plomberie de transfert de données. Le vrai travail se fait en amont, lors de la conception des tables et de l'écriture des requètes, vues et autres procédures stockées...

          * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

          • [^] # Re: Mmmm, voyons voir...

            Posté par  (site Web personnel) . Évalué à 1.

            Pmo découvre à chaque execution le schéma des tables qu'on passe au controller. Cela représente un temps d'exécution infime du fait du caching et des perfs des SGBD. Bien entendu, une fois que le controller t'as crée les objets, tu n'as plus besoin d'intérroger le SGBD ! Tu travailles directement sur tes objets jusqu'au moment du commit();

            Ce temps de découverte du schéma de la table via un DESC est beaucoup plus infime que s'il avait à accéder à un fichier xml en lecture ecriture + parsing comme les autres ORM.

            Au niveau des 10 000 lignes cela ne change rien, ta table peut également stocker 1 000 000 d'enregistrements.

            C'est l'optimisation de ta requête SQL qui est importante, et ça il n'y a que toi qui peut le faire.

            PMO est une couche d'abstraction objet c'est aussi de la plomberie, c'est sur que ça n'est pas aussi bien que si c'était un module PHP à part entière car il utilise d'autres couches d'abstraction en dessous .
            • [^] # MultiDeskOS inside

              Posté par  . Évalué à 2.

              Aussi loin que je comprenne ton design (je ne suis pas dev PHP), chaque objet MyObject correspond exactement a une (et une seule) table. Et les MyMap permettent regrouper ces objets cote à cote avec des bon tableaux à l'ancienne. C'est bien, mais si on danse mais si tu veut faire du relationnel ?

              ORM signifie « Object Relation Mapping » : le but est avant tout d'abstraire les relations entre les objets. S'ils s'agissait seulement de saupoudrer les noms de tables et colonnes d'une pincée de syntaxe objet-like, on aurait surement appelé ça OTR (comme object table mapping).

              Pour rester dans les exemples bateau, imagine que j'ai une entité "Utilisateur" et une entité "Addresse" (un Utilisateur ayant une seule Addresse, pour
              faire simple). Je souhaite évidement pouvoir faire des choses du type :

              $user = Utilisateur::getByName("Mickael Kael");
              $user->address->setTown("Muflin");
              $user->save();

              Dans cet exemple on voit comment la relation pourrait être "abstraite" de la couche de persistance. En outre on aimerais pouvoir charger paresseusement (lazy loading) les objets et leurs attributs. Surtout lorsqu'on va sélectionner en profondeur (ex. ne pas charger toute les tables traversées (en plus, a coups de "SELECT *" !) en mémoire lorsqu'on fait un $user->client->address->town->getPostcode() sur un objet précis alors que pour ses congénères on n'utilise que $user->getClient()).

              Si j'ai bien compris, pour le moment, l'utilisateur doit gérer ces relations à la main en écrivant ses requêtes et en agrégeant/associant manuellement les objets d'une même « ligne » (sic) du tableau MyMap, et en moulinant à l'ancienne pour reconstruire les liens en deréférençant les fkeys. Mais alors, quel intérêt d'un ORM (ou même, d'une vue objet) ?

              > Le design pattern de pmo est documenté

              J'ai lu le manuel indiqué en lien dans le journal (ici c'est culture Unix, alors si le man ne documente pas tout et qu'il faut lire des divx pour connaitre l'API...), mais je crois que tu n'avais pas compris mes remarques.

              > PMO implémente par exemple active record, et fait même plus que cela [...]. PMO est plus souple que ADOdb [...] et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.

              Et sinon ça va les chevilles ?

              > PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql

              Ce que je voulais dire, c'est qu'ADOdb offre une API permettant de s'affranchir des petites différences de syntaxe SQL entre les divers moteurs (ce n'est pas seulement une façon d'unifier les drivers sgbd de php). Enfin bon c'est assez secondaire par rapport aux autres problèmes de PMO.
              • [^] # Re: MultiDeskOS inside

                Posté par  (site Web personnel) . Évalué à 1.

                Chaque MyObject correspond à un tuple limité à sa table car PMO a découpé les résultats de la requete sql et instancié des objets spécifiques. Il n'y a pas d'autres ORM qui font ça à l'heure actuelle.

                Pour répondre à ta question concernant le relationnal mapping effectivement PMO est pour le moment rudimentaire au niveau manipulation des maps, il y a les structures de données, mais pas les méthodes pour travailler dessus, pas d'itérateurs non plus;

                De même Pmo ne gère pas le casting, comme tu l'as très justement fait remarqué PMO n'implémente pas de design pattern lazy loading (c'est d'ailleurs le sujet de ce fil). Il y a plein de choses à faire.

                Enfin je pense que c'est facile de trouver des défauts à une API taguée 0.07 avec 1 développeur qui rédige les docs, le manuel, pond des articles sur les sites. C'est plus simple pour moi de faire un screencast que d'organiser des conférences power point (j imagine que tu le comprendras) ;)
      • [^] # Re: Mmmm, voyons voir...

        Posté par  (site Web personnel) . Évalué à 1.

        Sauf que tu généralise le cas pour un objet user...

        Il vaudrais mieux un truc comme ça :
        $pmo = pmo_record::singleton()->get_by_login('ancienLogin');
        $pmo->login = 'nouveaulogin';
        $pmo->commit();

        J'ai mis pmo_record::singleton()->get_by_login au lieu de pmo_record::get_by_login pour avoir a éviter des problèmes entre fonctions statiques et non qui peux générer des erreurs strictes.

        Après tu ajoute dans ta classe pmo_record (enfin un classe qui gère qu'une ligne) deux fonctions magiques :
        public function __call($name,$param); //pas sûr du prototype, voir doc
        Elle va se charger de décrypter ton get_by_xxx qui n'existe pas, que tu va mapper vers une fonction get_by qui prend un tableau de toutes les conditions a utiliser pour faire la clause where du select.

        Ensuite pour le $pmo->login, tu utilises une fonction magique :
        public function __set($key, $value);

        Comme ça ton attribut est affecté sinon tu plante.

        En bonus on peux imaginer que la fonction singleton a le prototype suivant :
        public static singleton($table_name);
        Et va se charger de créer un objet vide pour la table avec les bonnes données (NULL quand la table mysql est a null ou valeur par défaut).

        Bon ça risque de poser des petits soucis pour implémenter un gestion de l'id automatique.

        ps : ceci est fortement inspiré de l'active record de ruby, et le plus serait de le coder en module php et plus en php tout court ;)
        • [^] # Re: Mmmm, voyons voir...

          Posté par  (site Web personnel) . Évalué à 0.

          pareil qu'au dessus, je n'arrive pas à répondre à ton post :/ Le code de pmo ne doit pas être apprécié par le parser de linuxfr :/

          Ma réponse ici:
          http://code34.girafon.org/reponse2.txt
          • [^] # Re: Mmmm, voyons voir...

            Posté par  (site Web personnel) . Évalué à 2.

            Je n'utilise pas les magiques car je ne trouve pas ça propre.

            $pmo->login = 'nouveaulogin';
            En terme de lisibilité, c'est mal, même si derrière ça fait appel à une
            méthode et que la variable est protected.

            La deuxième raison c'est que les objets de PMO sont extensibles, et que
            l'utilisateur peut utiliser ces propres objets grace au polymorphisme.
            Implémentation des magiques pour d'autres fonctionnalités.

            Comparaison:
            $pmo = pmo_record::singleton()->get_by_login('ancienLogin');
            $pmo->login = 'nouveaulogin';
            $pmo->commit();


            Le code PMO actuel
            $object = $map->getObjectByValue('utilisateur","login","ancienLogin");
            $object->setAttribute("login","nouveaulogin");
            $object->commit();

            Etant donné que cela fait quand même plusieurs fois qu'on me soumet cette
            évolution, je vais tout de même y réfléchir.

            Au niveau de la méthode singleton, cela est implémenté de cette manière:
            $object = $controler->createObject("utilisateur");

            Le controleur va créer l'objet avec les bons attributs initialisés à blanc. Il
            est fort possible que dans la prochaine version la méthode create soit intégré
            dans l'objet

            $object->create('utilisateur");
            • [^] # Re: Mmmm, voyons voir...

              Posté par  (site Web personnel) . Évalué à 2.

              Code34 : j'ai posté ton commentaire pour tester, et visiblement, j'y suis arrivé. Pourrais-tu me dire ce qui t'as bloqué et quelle(s) erreur(s) ont été retournée(s) par templeet ?
              • [^] # Re: Mmmm, voyons voir...

                Posté par  (site Web personnel) . Évalué à 1.

                En fait, je cliquais sur verifier, et la je voyais en attente du serveur s'afficher tout en bas. Au bout d'un certains temps: "impossible d'afficher la page". Alors qu'en postant les autres commentaires ci-dessus, je n'ai rencontré aucun problème.
            • [^] # Re: Mmmm, voyons voir...

              Posté par  (site Web personnel) . Évalué à 1.

              Merci Bruno ;) Je ne sais pas pourquoi cela ne marchait pas. Je suis entrain de commiter le cvs avec les modifications évoqués ci-dessous.

              J'ai implémenté le __set() et __get() dans l'objet. Je garde une réserve pour l'implémentation de ces méthodes dans la map.

              J'ai également corrigé la faute controler -> controller
              • [^] # Re: Mmmm, voyons voir...

                Posté par  (site Web personnel) . Évalué à 2.

                Bon en fait personnellement au début je pensais que c'était pas propre.

                Mais finalement ça marche bien si tu documentes les choses correctement...

                Bon en fait je suis en train de repenser une application et avoir un pmo qui agis au niveau record ça me serait assez pratique.

                A savoir ton controleur est a initialiser une fois au début.
                (il se charge de se mettre en global et compagnie)

                Après tu ne fait plus qu'appel a :
                $record = record::singleton('table');
                Ton singleton va faire ça :
                - public static singleton($table, $id = null)
                - récupération du controleur si existant, instanciation d'un nouveau au besoin
                - créer l'objet avec les attributs et valeurs par défaut de la table
                - retourner l'enregistrement

                Après il n'y a plus qu'a faire joujou avec.

                Par contre tout ce qui est dérivation de l'objet est a mon avis pas un problème avec les magiques.

                Pour la bonne et simple raison que l'objet dérivé devra simplement veiller a appeller parent->magique() avant de faire son code a lui.

                Ainsi ça marche au poil.

                Après il y aurait plusieurs classe a faire :
                - controleur
                - record
                - liste de record

                Et bien sur tu te débrouille pour placer les objets dans une table de hashage du controler pour qu'il renvoie l'objet précédent si on a un couple table+id identique...
                • [^] # Re: Mmmm, voyons voir...

                  Posté par  (site Web personnel) . Évalué à 1.

                  Raphael,

                  A mon avis tu te poses des problèmes, ou il n'y en a pas ;)

                  dans pmo
                  controleur = controller
                  record = objet
                  liste de record = map

                  Le controleur n'a pas besoin d'être singleton. Le role du controleur c'est de remplir les maps avec des objets qu'il instancie. Lui il n'est en fait qu'un objet vide avec des méthodes qui stocke des références. Bien que ça soit inutile, tu peux instancier plusieurs controleurs, ou garder dans une variable de ta propre classe une référence vers le controlleur que tu utilises. Mais c'est aussi tout à fait correct d'utiliser 2 controlleurs différents en parallèle.

                  La table de hashage existe également c'est un objet à part entière ;)

                  Pour le __set et __get j'ai implémenté les méthodes hier soir, dispo sur le subversion;
                • [^] # Re: Mmmm, voyons voir...

                  Posté par  (site Web personnel) . Évalué à 1.

                  J'oubliais, comme je vois que ma doc n'a pas l'air très claire, peux tu me remonter tous les trucs qui ne sont pas évidents ou qui prêtent à confusion ?
                • [^] # Re: Mmmm, voyons voir...

                  Posté par  . Évalué à 4.

                  > Bon en fait je suis en train de repenser une application et avoir un pmo qui agis au niveau record ça me serait assez pratique.

                  Au cas où tu ne l'ai pas déjà fait, il pourrait être prudent de jetter un oeil sur les frameworks complets existants, faits par des gens qui connaissent les besoins caractéristiques (des fw qui sont utilisés en prod, par exemple), et pas par des étudiants qui croient découvrir la lanterne magique.

                  Peut-être quelque chose comme :
                  http://www.cakephp.org/
                  http://www.symfony-project.com/
                  http://seagullproject.org/
                  etc.

                  En outre le choix de licence (GPLv3) de phpmyobjet t'impose de passer ton appli sous ce régime, et de ne pas utiliser d'autres libs sous une licence incompatible (comme, au hasard, GPLv2, LGPL, openssl, ...), ce qui est un beau sacrifice pour une telle lib.

                  Outre les critiques adressées ici, un exemple tiré du code source :

                  public function getAttribute($name) {
                  if(isset($this->object_attribute[$name]))
                  return $this->object_attribute[$name];
                  return FALSE;
                  }

                  J'imagine que la gestion des exceptions, ou différencier les attributs inexistants des attributs vides, c'est secondaire chez PMO...
    • [^] # Re: Mmmm, voyons voir...

      Posté par  (site Web personnel) . Évalué à -2.

      Depuis quand un select * est goret ?

      -1 Pour le troll php et sql ;)
      • [^] # Re: Mmmm, voyons voir...

        Posté par  (site Web personnel) . Évalué à 2.

        Depuis quand un select * est goret ?

        C'est l'utilisation systématique du SELECT * qui est gorête. On ne doit sélectionner que les champs dont on a besoin. Tout tirer de la base de données pour coller dessus du "mapping machin-chose", pour moi, c'est lourd et disgracieux. Voilà pourquoi.

        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

        • [^] # Re: Mmmm, voyons voir...

          Posté par  (site Web personnel) . Évalué à -1.

          C'est une erreur de penser cela car les perfs des sgbd dépendent de leurs plans d'executions. Un select colonne n'est pas plus rapide qu'un select * quand il n'est pas sur une colonne indexé.

          En plus, si par exemple tu as une table utilisateur, utiliser des select précis sur les colonnes signifie que derrière tu vas avoir autant de méthodes que de select pour modifier ces colonnes.

          Au final, tu vas avoir une quantité de code qui va croite à chaque fois que t apporteras des modifications à tes tables. Rajouter d'une méthode par exemple pour parametrer le login, le mail , le pass etc ... Au final, ton gain de performances sera à peine quantifiable, et par contre ton code sera tellement gros qu'il te sera de plus en plus difficile de le maintenir.

          PMO pourrait utiliser des select sur des colonnes mais ça n'a pas d'intérêt, étant donné qu'il te donne un objet qui représente une ligne de ta table, et tu peux à partir de cet objet filtrer ce que tu veux utiliser. Tout le select n'est donc pas renvoyé comme ça.

          Je sais très bien que je n'arriverais pas à te convaincre, il y a tout de même un bench ici
          http://pmo.developpez.com/versions/0.07/#LIII
          • [^] # Re: Mmmm, voyons voir...

            Posté par  . Évalué à 8.

            C'est une erreur de penser cela car les perfs des sgbd dépendent de leurs plans d'executions. Un select colonne n'est pas plus rapide qu'un select * quand il n'est pas sur une colonne indexé.

            On ne te parle pas de traitement de requête mais de transfert sgbd->php, de deux chose l'une :
            - soit tu charges systématiquement toutes les données de ta ligne, et donc sur une table avec plein de champs tu vas tout charger même ce dont tu n'as pas besoin -> overhead coûteux inutile.
            - soit tu charge les attributs de ta ligne a la demande et la tu multiplie les échanges entre ta librairie cliente du SGDB et ton serveur -> overhead coûteux inutile.

            Sachant qu'un outil de mapping objet se doit être très générique pour coller a un maximum de besoin, tout les types d'usages doivent être satisfaisant : pas moyen de s'en sortir en disant a ton utilisateur qu'une table a 80 colonne c'est débile (même si dans l'absolu, c'est vrai : tu n'es pas maitre de ses contraintes. Pour ma part je fait de la BD géographique, et des champs peuvent être très gros, sans que l'on veuille forcément les charger).

            En plus, si par exemple tu as une table utilisateur, utiliser des select précis sur les colonnes signifie que derrière tu vas avoir autant de méthodes que de select pour modifier ces colonnes.

            Au final, tu vas avoir une quantité de code qui va croite à chaque fois que t apporteras des modifications à tes tables. Rajouter d'une méthode par exemple pour parametrer le login, le mail , le pass etc ... Au final, ton gain de performances sera à peine quantifiable, et par contre ton code sera tellement gros qu'il te sera de plus en plus difficile de le maintenir.


            Gni ? c'est pas géré en dynamique tout ca ? le premier truc que j'attendrais d'un mapping c'est de justement que mes méthodes soient crées automagiquement ! m'enfin je sais pas si php permet ce genre de choses :) (autrement que par un générateur de code)

            PMO pourrait utiliser des select sur des colonnes mais ça n'a pas d'intérêt, étant donné qu'il te donne un objet qui représente une ligne de ta table, et tu peux à partir de cet objet filtrer ce que tu veux utiliser. Tout le select n'est donc pas renvoyé comme ça.

            C'est fumeux. J'ai l'impression que tu parts du principe que ton analyse est la bonne et que tu défends le fonctionnement. Profite des exigeants lecteurs de linuxfr et donne leur en pature ton travail en expliquant comment tout cela fonctionne plutôt que d'essayer d'expliquer pourquoi c'est bien. Ton projet a l'air jeune, tu t'es fait la main sur les premières versions, c'est peut être l'heure de tout casser pour repartir sur du propre et débattu :)
            • [^] # Re: Mmmm, voyons voir...

              Posté par  (site Web personnel) . Évalué à -1.

              Ne mélangeons pas tout, tu me parles de problèmes qui n'ont rien à voir avec PMO. Pour comprendre l'intérêt de PMO, il faut avoir un minimum de fondamentaux en OO.

              On ne te parle pas de traitement de requête mais de transfert sgbd->php,

              problème d'infra

              soit tu charges systématiquement toutes les données de ta ligne, et donc sur une table avec plein de champs tu vas tout charger même ce dont tu n'as pas besoin

              Les problèmes que tu te poses ne sont pas liés à PMO mais à ton mcd, ou ton diagramme de collaboration/classes. Tu as mal conçu ton programme, de ce fait tes objets possèdent des attributs qu'il ne devraient pas posséder / manipuler.

              soit tu charge les attributs de ta ligne a la demande et la tu multiplie les échanges entre ta librairie cliente du SGDB et ton serveur

              PMO ne fonctionne pas comme ça

              Sachant qu'un outil de mapping objet se doit être très générique pour coller a un maximum de besoin, tout les types d'usages doivent être satisfaisant : pas moyen de s'en sortir en disant a ton utilisateur qu'une table a 80 colonne c'est débile (même si dans l'absolu, c'est vrai : tu n'es pas maitre de ses contraintes. Pour ma part je fait de la BD géographique, et des champs peuvent être très gros, sans que l'on veuille forcément les charger).

              PMO n'est pas là pour pallier à des problèmes de conception. Si tu as une table avec 80 colonnes, c'est que t'as déjà un problème flagrant de MCD. De même PMO n'exclue pas la possibilité d'utiliser des colonnes. Tout dépend de l'implémentation de la class du parser SQL

              gni ? c'est pas géré en dynamique tout ca ? le premier truc que j'attendrais d'un mapping c'est de justement que mes méthodes soient crées automagiquement ! m'enfin je sais pas si php permet ce genre de choses :) (autrement que par un générateur de code)

              C'est ce que j'expliquais au dessus quand on utilise par un mapper comme PMO, on multiplie les lignes de code.

              C'est fumeux. J'ai l'impression que tu parts du principe que ton analyse est la bonne et que tu défends le fonctionnement. Profite des exigeants lecteurs de linuxfr et donne leur en pature ton travail en expliquant comment tout cela fonctionne plutôt que d'essayer d'expliquer pourquoi c'est bien. Ton projet a l'air jeune, tu t'es fait la main sur les premières versions, c'est peut être l'heure de tout casser pour repartir sur du propre et débattu :)

              Tu me fais rire : "les exigeants lecteurs de linuxfr". Ce fil de discussion découle du fait qu'un exigeant lecteur n'a lu que partiellement les doc.

              Il y a des bonnes et des mauvaises critiques sur ce site, souvent on se retrouve confronté à des réactionnaires, mais ça n'en reste pas moins un média.

              De là à dire qu'il faut recommencer un projet juste pour améliorer l'implémentation de méthode dans la class parser ...
  • # Soyons chieur en ce lundi matin...

    Posté par  . Évalué à 3.

    Je viens de regarder les benchmarks sur ton site[1] et je vois que les résultats sont affichés de cette façon:

    lecture et création de 3000 objets 29 /sec 0,20 /sec

    Tel que je lis ça, j'en déduis que PMO v0.06 peut créer 29 objets par seconde (et PMO v0.07 en créerait 0,2 par seconde). Ce qui donne un léger (oui, j'aime les euphémismes) désavantage pour PMO 0.07

    Je suppose que tu voulais dire qu'il faut respectivement 29 et 0,2 secondes pour créer les objets?




    1 http://pmo.developpez.com/versions/0.07/#LIII

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.