samedi 11 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de Code34 :

Journal : PMO version 0.09

Posté par Code34 (page perso, ) le 16 septembre 2007
0
La version tout fraiche de PhpMyObject vient d'être mise à disposition:
http://pmo.developpez.com

Qu'est ce que PMO ?
Pmo est à PHP, ce qu'est Active Record pour Ruby on rails. Il s'agit d'une API qui crée une couche d'abstraction relationnelle objet entre les gros SGBD du marché et votre application PHP.

L'intérêt ? Des données plus faciles à manipuler, et à écrire en base.

Le manuel avec des exemples:
http://pmo.developpez.com/manuel/

> Lire le journal (8 commentaires, moyenne: 2).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

[+] argh !

Posté par Jacquot Raphael () le 16/09/2007 à 18:12. (lien). Évalué à -8.

deja qu'en ruby c'est horriblement lent et ca bouffe des quantites monstrueuses de ressources, j'ose pas imaginer ce qu'un truc pareil peut donner en php..
a reserver a des mini-sites ou pas grand chose ne se passe, assurément

  • [^]Re: argh !

    Posté par Code34 (page perso, ) le 16/09/2007 à 18:47. (lien). Évalué à 4.

    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.

    • [^]Re: argh !

      Posté par Yusei () le 17/09/2007 à 05:10. (lien). Évalué à 3.

      Un élément de réponse au niveau des performances sans tester et sans regarder comment fonctionne PMO: dans la plupart des configurations "de base" de PHP, les scripts sont re-analysés à chaque requête. ActiveRecord garde en cache le schéma de la base de données, ce qui lui permet de ne pas être trop lent (en gardant dans l'idée que ça reste du Ruby), et PMO ne peut pas faire ça dans les cas où le script est relancé dans un nouvel environnement à chaque requête. Il y a donc un risque que ce soit lent

      Évidemment, pour une application sérieuse, on doit pouvoir faire en sorte d'une part de ne pas réanalyser le script à chaque requête, d'autre part des garder des infos en cache, même en PHP. C'est juste que ce n'est pas le comportement par défaut.

      • [^]Re: argh !

        Posté par Code34 (page perso, ) le 17/09/2007 à 08:27. (lien). Évalué à 1.

        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.

  • [^]Re: argh !

    Posté par Snarky (Jabber id, page perso, ) le 16/09/2007 à 21:00. (lien). Évalué à 5.

    Je sais pas si c'est a cause de la saison, mais j'avais lu rugby... Je comprenais pas trop la phrase du coup ^^

    --
    Milite pour un about:black sur les navigateurs ! (Sauvons la planète)

mouais...

Posté par fabien () le 16/09/2007 à 18:52. (lien). Évalué à 2.

alors donc

while($result=mysql_fetch_object($res)
{
echo $result->nom;
}

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

bof bof...
d'autant que l'on est limité a des "select *"

ha si, c'est vrai on a un niveau d'abstraction : on peu facilement changer de moteur de base de données...
bon, j'crois que je vais attendre la v1.0 moi ;)

  • [^]Re: mouais...

    Posté par Code34 (page perso, ) le 16/09/2007 à 18:59. (lien). Évalué à 2.

    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/

  • [^]Re: mouais...

    Posté par Thierry Boudet (page perso, ) le 16/09/2007 à 20:11. (lien). Évalué à 7.

    bof bof...
    d'autant que l'on est limité a des "select *"

    Encore ?????

    --
    ( images )

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0669s (dont 0.0099 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !