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
Journal PhpMyObject - nouvelle version 0.02
3
juin
2007
# Intérêt?
Posté par Bastien Leblanc (site web personnel) . Évalué à 1.
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 . Évalué à 9.
[^] # Re: Intérêt?
Posté par Code34 (site web personnel) . Évalué à 2.
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) . Évalué à 2.
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) . Évalué à 2.
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) . Évalué à 2.
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) . Évalué à 2.
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) . Évalué à 1.
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) . Évalué à 1.
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) . Évalué à 1.
[^] # Re: Bien bien...
Posté par Dinofly (site web personnel) . Évalué à 1.
http://fr2.php.net/manual/fr/function.PDOStatement-fetch.php
[^] # Re: Bien bien...
Posté par Code34 (site web personnel) . Évalué à 1.
[^] # Re: Bien bien...
Posté par Nicolas Blanco (site web personnel) . Évalué à 1.
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 . Évalué à 2.
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) . Évalué à 1.
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) . Évalué à 2.
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) . Évalué à 1.
# Et pourquoi pas un phppgobject ?
Posté par ioguix . Évalué à 1.
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) . Évalué à 1.
[^] # Re: Et pourquoi pas un phppgobject ?
Posté par ioguix . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.