Journal PhpMyObject - nouvelle version 0.02

Posté par Code34 (site web personnel) le 03 juin 2007 à 17:10.

Étiquettes : aucune

juin

2007

J'ai le plaisir de vous annoncer une nouvelle release de Phpmyobject. Le code a été réécrit à 70%

Petit rappel:
=========
Phpmyobject permet de générer des objets php en mappant des bases mysql

Les grandes nouveautés de cette version:
=================================
- Un parser SQL
- Un nouveau controleur qui gère l'unicité des objets en se basant sur les primary keys beaucoup plus léger et performant
- Un mappage qui permet de manipuler plusieurs types d'objets
- des interfaces controleur et parser

Cette version marche bien, et je vous invite à l'essayer dès maintenant.

un extrait du README:
$toto = new mycontroler();
$toto->queryControler("SELECT * from db_user,db_town where db_user.town_id=db_town.town_id;");
$map = $toto->getMap();

In this example, the controler will do:
one object user, and one object town

you can after this manipulate them like this:
foreach ($map as $row){
echo($row[id]); /* will print the linking join id */
echo($row[table]); /* will print the object type refer to table */
echo($row[object]); /* will print the object */
}

object can be acces like this:
=============================

$row[object]->getListAttribute(); /* will return all the attribute of the object */
$row[object]->getAttribute($name); /* will return the value of one attribute */
$row[object]->setAttribute($attributename, $attributevalue) /* will set the attribute value */

http://sourceforge.net/project/showfiles.php?group_id=194398

# Intérêt?

Posté par Bastien Leblanc (site web personnel) le 03 juin 2007 à 19:23. Évalué à 1.

Bonsoir,

Au fond quel intérêt par rapport à ce qui se fait déjà?

Notamment Le package MDB2 de Pear http://pear.php.net/package/MDB2 ?
- [^] # Re: Intérêt?
  
  Posté par nicodache le 03 juin 2007 à 20:31. Évalué à 9.
  
  la liberté de choisir ?
- [^] # Re: Intérêt?
  
  Posté par Code34 (site web personnel) le 03 juin 2007 à 21:58. Évalué à 2.
  
  Ca ne fait pas la même chose que Pear.
  
  Plus de détails par rapport aux autres projets dans mon post précédent
  http://linuxfr.org/~Code34/24247.html
- [^] # Re: Intérêt?
  
  Posté par Cyrille Pontvieux (site web personnel, Mastodon) le 04 juin 2007 à 12:31. Évalué à 2.
  
  MDB2 ne fait pas de mapping Objet. C'est plutôt un espèce de wrapper d'appel à des bases relationnelles (qu'il fait très bien d'ailleurs).
  
  Le seul souci avec MDB2 c'est pour la gestion du modèle de la base, son schéma. Le module MDB2_Schema (qui permet de gérer son schéma voire ses données, faire des migration de shéma, du reverse...) est encore en bêta et porte très bien sa dénomination malheureusement : ça avance très peu. Manque de développeurs, de motivation ? Certainnement les deux.
  
  On peut ajouter un mapping objet au dessus de MDB2, mais c'est n'est pas celui-ci qui permet de le gérer. PHPMyObject est un peu l'équivalent d'Hibernate en Java. C'est encore assez rudimentaire mais largement utilisable et avec PHP 6 - très orienté objet - ça devrait donner un nouveau souffle au PHP.
# Bien bien...

Posté par Nicolas Blanco (site web personnel) le 04 juin 2007 à 00:21. Évalué à 2.

Je testerai la prochaine fois que je programmerai en PHP (hihihi).

Vu qu'on parle d'ORM j'en profite pour parler de mon préféré, désolé :).
Pour moi, l'ORM presque parfait existe déjà et il s'appelle ActiveRecord (Ruby).
Quel bonheur de l'utiliser...

Pour ceux qui connaissent pas :

employes = Employe.find(:all)
--> select * from employes;

employe = Employe.find_by_nom_and_prenom("Blanco", "Nicolas")
--> select * from employes where nom = 'Blanco' and prenom = 'Nicolas';

nb_employe = Employe.count
--> select count(*) from employes;

employe.departement.nom ==> "Informatique"
--> select * from departements where departement_id = 1

employes = Employes.find(:all, :conditions => { :grade => 9..12, :sortie => nil })
--> select * from employes where grade between 9 and 12 and sortie is null;

Ce qui tue c'est dès qu'on veut utiliser les paramètres renvoyés par le user via un formulaire par exemple (sans compter que les paramètres sont automatiquement nettoyés pour éviter les injections).

employe = Employe.create(params[:employe])
--> prends tous les paramètres retournés dans le formulaire, mappe un objet et fais l'INSERT dans la table. C'est la même ligne, qu'il y ai 2 champs dans le formulaire ou 50 ! Il suffit juste de nommer les champs du formulaire avec le nom des colonnes dans la table et le tour est joué.

Sans compter tout ce qu'il y a autour (gestion transactionnelle : rollback automatique de la table en cas d'exception lors de la manipulation d'un modèle, etc), callbacks, etc.

Je n'ai pas encore trouvé d'ORM aussi complet, rapide et efficace en PHP...
- [^] # Re: Bien bien...
  
  Posté par Code34 (site web personnel) le 04 juin 2007 à 09:21. Évalué à 2.
  
  Je pense qu'il y a une incompréhension par rapport à ce que fait Phpmyobject.
  
  Phpmyobject n'est pas un générateur de requêtes sql comme l'exemple que tu donnes ci-dessus.
  
  Il n'est pas non plus un ensemble d'objets qui permettent de manipuler un sgbd comme pear.
  
  Phpmyobject est un générateur d'objet. Il ne crée pas des objets dans les bases du sgbd, il crée des objets dynamiquement du coté du serveur d'application à partir des résultats d'une requête sql.
  
  La différence fondamentale entre le fetch object de php tel qu'il est implémenté et phpmyobject sont:
  
  - le fetch object de php renvoit 1 seul et unique object par tuple. Cette objet à ma connaissance n'embarque aucune méthode, et récupère en propriété tout les champs du tuple
  
  - phpmyobject retourne autant d'objets qu'il y a de tables par tuple. Ces objets récupèrent dynamiquement les propriétés des attributs de la table, et embarque avec eux des méthodes qui permettent de récupérer et modifier ces objets, d'ailleurs ces objets peuvent être très bien étendu.
  - [^] # Re: Bien bien...
    
    Posté par Laurent J (site web personnel, Mastodon) le 04 juin 2007 à 09:58. Évalué à 2.
    
    le fetch object de php renvoit 1 seul et unique object par tuple. Cette objet à ma connaissance n'embarque aucune méthode, et récupère en propriété tout les champs du tuple
    
    Utilise PDO disponible dans php5 : tu peux indiquer la classe à utiliser pour l'instanciation des objets (donc indiquer tes propres classes).
    - [^] # Re: Bien bien...
      
      Posté par Code34 (site web personnel) le 04 juin 2007 à 10:39. Évalué à 1.
      
      Ca n'a pas de rapport. Pdo permet de manipuler les résultats du sgbd, tout comme le fait pear.
      
      Tu peux implémenter l'interface controleur, et sqlparser de phpmyobject en utilisant pear ou pdo, ça n'a pas d'importance, mais ça n'intervient pas au même niveau.
      
      pdo et pear sont des objets qui manipulent des sgbd.
      phmyobjet crée des objets dynamiquement calqué sur le modèle relationnel de ta base.
      - [^] # Re: Bien bien...
        
        Posté par Laurent J (site web personnel, Mastodon) le 04 juin 2007 à 11:41. Évalué à 1.
        
        si ça un rapport : je t'indique juste que le premier avantage que tu indiques dans ton commentaire précédent n'est pas valable puisque PDO le fait déjà.
        
        Je n'ai pas dit par contre que PDO faisait ce que tu décris dans le deuxième avantage.
        
        [^] # Re: Bien bien...
        
        Posté par Code34 (site web personnel) le 04 juin 2007 à 12:30. Évalué à 1.
        
        Je ne citais pas ça en tant qu'avantage, je décrivais vulgairement l'implémentation du fetch object de php5. S'il y a un module comme pdo qui permet de manipuler les résultats des requêtes sql plus précisement en oo c'est très bien.
      - [^] # Re: Bien bien...
        
        Posté par Dinofly (site web personnel) le 04 juin 2007 à 11:47. Évalué à 1.
        
        Mais est-ce que ça ne serait tout de même pas comparable à PDO ?
        
        PDO::FETCH_CLASS: retourne une nouvelle instance de la classe demandée, liant les colonnes du jeu de résultats aux noms des propriétés de la classe. Si fetch_style inclut PDO::FETCH_CLASS (c'est-à-dire PDO::FETCH_CLASS | PDO::FETCH_CLASSTYPE), alors le nom de la classe est déterminé à partir d'une valeur de la première colonne.
        
        http://fr2.php.net/manual/fr/function.PDOStatement-fetch.php
        
        [^] # Re: Bien bien...
        
        Posté par Code34 (site web personnel) le 04 juin 2007 à 12:37. Évalué à 1.
        
        peut être mas pas sur ...
  - [^] # Re: Bien bien...
    
    Posté par Nicolas Blanco (site web personnel) le 04 juin 2007 à 23:23. Évalué à 1.
    
    ok, j'ai bien compris.
    
    mais bon, pourquoi ne pas utiliser un ORM directement qui fera tout en même temps : générer les requêtes, mapper les résultats dans un objet et proposer des méthodes pour facilement itérer dessus afin de créer des tableaux et j'en passe ?
    - [^] # Re: Bien bien...
      
      Posté par Axel le 05 juin 2007 à 09:39. Évalué à 2.
      
      Parce qu'il n'y en a pas, ou peu. Mis à part ezpdo, je n'en connais aucun.
      
      C'est ce qui fait défaut avec le php, on est obligé de réécrire souvent la même chose, par manque de frameworks de qualités et maintenus.
    - [^] # Re: Bien bien...
      
      Posté par Code34 (site web personnel) le 05 juin 2007 à 13:36. Évalué à 1.
      
      J'insiste vraiment sur ce fait: phpmyobject ne mappe par les résultats dans un objet
      
      phpmyobject mappe 1 ligne de résultat dans autant d'objets qu'il y a des tables concernées
      
      Je pense (et je peux me tromper car je n'en ai pas personnellement l'utilité) que c'est une mauvaise idée de développer un outil qui proposerait une abstraction à SQL si celle-ci n'apporte pas des fonctionnalités plus puissantes.
      
      Bien entendu libre à chacun de proposer des évolutions.
    - [^] # Re: Bien bien...
      
      Posté par Laurent J (site web personnel, Mastodon) le 07 juin 2007 à 14:15. Évalué à 2.
      
      ce que tu décris ressemble fortement à jDao dans le framework Jelix.
      
      Tu as juste un fichier dans lequel tu déclares sur quelle tables et quelles propriétés l'objet dao sera mappé. Tu peux aussi decrire des methodes : nom, type (select, update...), les propriétés à prendre en compte, les conditions etc..
      
      Et jDao te compile tout ça sous une forme de classe PHP, avec toutes les méthodes qu'il faut et que tu as décris, contenant alors les requêtes SQL correspondantes. Cette classe est mise en cache (donc pas de recompilation à chaque appel). le fait que les requêtes soient déjà générée et le code mis en cache apporte des performances respectables pour un orm.
      - [^] # Re: Bien bien...
        
        Posté par Code34 (site web personnel) le 07 juin 2007 à 19:52. Évalué à 1.
        
        Le mieux c'est que tu l'essaies, tu comprendras ce que fait pmo par rapport aux autres projets.
# Et pourquoi pas un phppgobject ?

Posté par ioguix le 04 juin 2007 à 14:04. Évalué à 1.

Salut,

Je me demandais si tu pensais à étendre ton projet à autre chose que MySQL et plus particulièrement à PostgreSQL ?

Je n'en ai pas réellement le besoin, c'est juste histoire d'équilibrer un peu le nombre de projet tournant autour de ces deux bases...Car il faut avouer que si MySQL a eu tant de succès, c'est aussi beaucoup grâce aux projets gravitant autour de ce dernier.

Or, je pense que PosqtgreSQL doit avoir sa place au moment de la conception des applications lorsque la question de la base se pose.

Bref, je suis prêt à contribuer à ton projet dans ce sens s'il le faut.

++
- [^] # Re: Et pourquoi pas un phppgobject ?
  
  Posté par Code34 (site web personnel) le 04 juin 2007 à 15:16. Évalué à 1.
  
  Je suis preneur, envoie moi le code(car je ne connais pas l'implémentation postgress), et je ferais évoluer la class sgbd
  - [^] # Re: Et pourquoi pas un phppgobject ?
    
    Posté par ioguix le 04 juin 2007 à 15:45. Évalué à 1.
    
    cf. en mp alors

Suivre le flux des commentaires

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