Code34 a écrit 1035 commentaires

ça sera mon cadeau 2008, je viens de l'implémenter sur la version du svs :p

Le parser SQL a une méthode getField, mais aucun patch n'a été proposé dans ce sens au niveau de la class sgbd, comme ça n'était pas ma priorité, et qu'il y a 2 besoins contradictoires exprimés, ca a été déscopé de la v 0.11, cela fera parti des fonctionnalités 2008.

Voici les points qui diffèrent avec les autres ORM existant.

PMO est plus jeune, et je suis seul à bosser sur le projet.

PMO est une api. Il couvre une infime portion de ce que couvre les frameworks comme Zend, Cake, symphony. En ce sens, PMO pourrait très bien faire parti d'un des frameworks cité précédement pour améliorer la couche modèle de mvc.

Toutes les classes de PMO implémentent des interfaces. (ca semble évident mais les ORM qui datent de php4, héritent aussi des lacunes des architectures conçues au fil de l'eau sans interface.

Cela rend PMO facilement extensible (j'ai mis moins d'une heure pour développer le driver postgresql), facilement implémentable dans d'autres projets et cela permet aussi de remplacer des composants de PMO par des composants plus performants.

PMO est runtime. Il n'y a pas besoin de déclarer des schémas de bdd dans des fichiers xml. PMO s'adapte automatiquement aux schémas des BDD. En gros, en quelques minutes (en survolant le manuel), tu peux déjà manipuler les éléments de ta BDD.

PMO te permet de garder le contrôler sur la requête SQL qui est passé au SGBD. Cela est une faiblesse comme on en a discuté dans le post au dessus, mais aussi un point fort. Ca permet au développeur de savoir ce qui se passe.

En gros, simplicité, performance.

Il y a d'autres exemples

tiré de la doc php
echo($foo = 5 + "10 cochonnets";)
affiche 15

pour mieux comprendre l'évaluation
echo($foo = 5 + "string 10 cochonnets";)
affiche 5

C'est aussi ça qui a fait le succès de PHP. Que l'interpréteur soit tolérant à certaines aberrations, et qu'on puisse opérer sur différents types de variables sans caster explicitement. Le typage n'étant pas un concept évident pour les développeurs débutants qui voulaient seulement faire une page web (..)

Depuis les besoins ont évolués. Je suis du même avis que toi, l'idéal serait un typage plus fort, la déclaration explicite des variables, une normalisation des noms des fonctions, etc ... et pourquoi pas du tout oo. C'est d'ailleurs vers ça que tend la version 5 qui a apporté quand même pas mal de choses.

En même temps, d'autres langages oo que je ne citerais pas ici pour ne pas effrayer les adeptes du kernel linux sont beaucoup évolués sur ces critères ;)

je vais étudier le problème . Le but n'est pas de réimplémenter pour chaque SGBD un mappage vers les fonctions.

Je pense que la solution actuelle est la plus simple. Est-ce que hibernate mappe toutes les fonctions ?

Effectivement, c'est un point à améliorer.

Je pense que la couverture totale de l'abstraction se fera dans la roadmap en 0.12 en même temps que la gestion des alias.

Il est possible facilement de rajouter un mapper qui construirait les SELECT (car ça ne concerne que les SELECT) mais cela poserait des problèmes plus important que ça n'en résoudrait:

La plus part des problèmes de perfs sont liés à des requêtes sql mal écrites, ici le dev reste maitre de la requête passé au SGBD

De plus, tu ne changes pas de SGBD tout les jours

Et en dernier lieu, c'est pas le rôle de PMO d'implémenter des rustines pour corriger les implémentations exotiques du langage SQL des SGBD du marché ;)

En fait, il n'y a pas besoin de convertir la requête SQL, celle-ci est envoyé tel quel au SGBD.

PMO traite les résultats renvoyés par le SGBD

Cela implique que si tu souhaites changer de SGBD du jour au lendemain, il faudra réécrire tes requêtes SQL pour les adapter à l'implémentation SQL du SGBD.

Est-ce que tu peux préciser en quoi la maintenance devient horrible, parce que le but s'est justement de développer du gros site. Il y a peut être des paramètres que je n'ai pas pris en compte :D

Ce que tu indiques dans ton billet, as été pris en compte. Il s'avère que PMO récupère un desc des tables sur lesquels il travaille, qu'il insère dans des objets PMO_MyTable.

Cette intérrogation en terme de ressource est inexistante étant donné que le SGBD implicitement cache ses informations pour pouvoir travailler sur les données. Le SGBD ne fait que te renvoyer que ce qu'il a en cache: ça coute pinuts par rapport à un simple SELECT.

Si tu compares ce mécanisme à un mécanisme persistant de déclaration XML comme c'est le cas pour la plus part des autres ORM. C'est beaucoup plus lent, et couteux en terme de ressources d'ouvrir un fichier, de parser du xml, que d'intérroger le cache du SGBD ;) Sans compter les problèmes de mise à jour etc ...

Cacher les objets, ça sera peut être à l'étude dans les prochaines versions.

C'est plus que l'exemple que tu donnes, car tu peux séparer les tables dans ton while, chose qu'il n'est pas possible de faire avec mysql_fetch_object, et de les manipuler en tant qu'objets liés

exemple:

while ($result = $map->fetchMap()){
echo $result['employe']->nom;
echo $result['ville']->nom;
echo $result['employe']->ville->nom;
}


Pour le select * , effectivement ça va arriver mais dans la v0.11. A mon sens la fonctionnalité la plus importante sera l'aliasing de la v0.12

http://pmo.developpez.com/roadmap/

Ca me fais rire ce genre de billet qui n'apporte rien au genre. Si tu veux parler perfs base toi sur les benchs. Ton avis sur la performance php - python, c'est pas qu'il ne m'intérresse pas, mais ça vaut la même chose que l'avis de la mère Michu qui parle du beau temps.

Ce journal vise à demander un peu d'aide pour Nouveau, le driver nvidia reverse-engineeré.
Ce pilote vise à fournir un support 2D et 3D pour (presque) toute la gamme Nvidia, des TNT (NV04) aux Geforce 8 (NV50).

Il y a un truc mal expliqué dans ce journal et sur votre site, c'est à quoi sert votre driver par rapport à celui fournis par Nvidia ?

et la réponse se trouve quelques pages plus tard dans votre FAQ:

1.9. Why are you doing this?

We can't give you the answer, as each of the project members has his own motivation. Just a few answers from our staff, we got when this question was raised:

* Don't like binary blobs
* Want to give back to the OSS community
* Want to learn driver programming
* Yes, we can develop our own drivers regardless of what people at NVidia may think
* Support for missing features
* Support for operating systems not supported by NVidia (any PowerPC based OS for example)
* Just for the fun of it
* Binary driver keeps crashing even in 2D
* Slow Xorg "nv" driver (slow in performance and slow to get new card support (Nvidia 8800 is currently not supported))

So pick the reasons you feel are important, chances are that quite a few project members will agree with you pick

Un récapitulatif en haut de la home page ne serait pas un luxe.

De l'extérieur, je pense que si Nvidia ne donne pas accès à tous ces drivers c'est qu'il y a des partis de microcodes stratégiques. De mémoire, certains drivers sont développés de tel ou tel façon pour contourner les erreurs de conception de l'architecture materielle, masquer de faibles performances etc ...

Il serait peut être intérressant pour vous de rentrer en contact directement avec Nvidia:

1- pour ne pas supporter le cout du développement entièrement alors que ça profite à Nvidia
2 - pour avoir des informations plus rapidement
3 - pour améliorer la qualité des drivers.

Au final factoriser le code commun à tous les drivers, et en faire un chargeur de plusieurs micro microcodes binaire sous LGPL pourrait être bénéfique à tous, sachant que potentiellement ce code pourrait être également utilisé par les cartes graphiques des autres marques ;)

ça se trouve c'est ce que vous faites déjà ? ça se trouve je me plante complètement :/

Toujours une bonne initiative de réussir à mettre les différents intervenants autour d'une table pour faire évoluer les RFC.

Irc.plus devrait avoir plus d'ambitions que simplement harmoniser les commandes. Il faudrait s'adapter au techno d'aujourd'hui et créer un vrai draft de ce que sera l'irc de demain (peut etre plus orienté vidéo, genre des chans avec des webcams qui s'affichent en mosaique, des avatars animés, des trucs pour afficher des documents formatés, etc ... )...

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) ;)

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 ...

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.

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 ?

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;

Effectivement, il y a une correction à apporter ;)

Oui c'est bien ça, Pmo v0.07 met 0,2 sec à créer 3000 objets avec une des tables de ref sakila

Alors que la v0.06 mettait 29 secondes.

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 ...

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 .

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

bizarre, je suis à ta dispo si tu as besoin de tests plus en profondeur.

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.