En vrac : Doctrine 2, MySQL 5.5 et VimGolf

Posté par (page perso) . Modéré par baud123.
18
30
déc.
2010
Technologie
Doctrine est une bibliothèque en PHP, sous licence LGPL, qui permet d'utiliser les enregistrements d'une base de données (relationnelle ou documents) sous forme d'objets PHP. Une réécriture complète avait commencé il y a deux ans et demi et vient d'aboutir sous la forme de la première version stable de Doctrine 2. Cette nouvelle version implémente maintenant le motif DataMapper (au lieu d'ActiveRecord précédemment), apportant ainsi plus de souplesse, de nouvelles fonctionnalités et une prise en charge de nouveaux moteurs de base de données dont MongoDB.

Oracle a annoncé le 15 décembre la sortie de la version 5.5 de MySQL, avec au programme amélioration des performances et meilleure prise en charge de la réplication et du failover. L'édition communautaire reste sous licence GPL et est toujours livrée avec les moteurs de stockage InnoDB, MyISAM, NDB, mémoire, archive, merge, etc. Il semblerait donc que MySQL soit l'un des rares projets Open Source à profiter du rachat de Sun par Oracle.

Pour finir, je souhaite vous présenter VimGolf. Le but de ces challenges de passer d'un fichier de départ à un fichier d'arrivée en tapant le moins de touches possible dans Vim. Bref, c'est un bon moyen d'apprendre à utiliser Vim de manière joyeuse :-)
  • # Vimgolf

    Posté par (page perso) . Évalué à 10.

    Au premier abord j'ai dit : tiens bonne idée de jeu à tester pour apprendre certaines manipulations que je ne dois pas connaître pour accélérer mon utilisation quotidienne de vi/vim et pourquoi pas diffuser le mot pour montrer aux gens comment utiliser vi/vim !

    MAIS en suivant les instructions il y a une étape très très très ********, c'est "Your VimGolf key: please sign in" obligation de se créer un compte à partir d'un compte twitter !

    Bonne initiative mais inscription horrible => direction les oubliettes !
  • # Doctrine2

    Posté par . Évalué à -4.

    Les possibilités et la souplesse qu'offre le couple ZendFramework2/Doctrine2 affirme la supériorité du langage PHP dans le domaine du développement web.
    La génération des modèles, formulaires et chaines de validation basée uniquement sur des fichiers de configuration, offre une abstraction absolue. Cela permet la génération de modèles de données complexes uniquement en ligne de commande. Ce que ne permet pas encore ruby on rails ou django.
    Doctrine fourni les outils M pour le MVC du Zend framework et il s'intègre particulièrement bien à ce dernier vu la grande qualité du code que fourni l'équipe du ZF.

    Dire que vous vous n'en avez rien à faire de la vie privée parce que vous n'avez rien à cacher, c'est comme dire que vous n'en avez rien à faire de la liberté d'expression parce que vous n'avez rien à dire. Edward Snowden

    • [^] # Re: Doctrine2

      Posté par (page perso) . Évalué à 2.

      Les goûts et les couleuvres, ça ne se discute pas. Personnellement, je suis bien content de ne pas avoir cette "abstraction" dans Rails et Django.

      Pour que chacun puisse juger, voici un petit exemple tiré du manuel [http://www.doctrine-project.org/docs/orm/2.0/en/reference/xml-mapping.html#example] :

      // Doctrine.Tests.ORM.Mapping.User.dcm.xml
      <?xml version="1.0" encoding="UTF-8"?>
      <doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
      http://www.doctrine-project.org/schemas/orm/doctrine-mapping.xsd">

      <entity name="Doctrine\Tests\ORM\Mapping\User" table="cms_users">

      <indexes>
      <index name="name_idx" columns="name"/>
      <index columns="user_email"/>
      </indexes>

      <unique-constraints>
      <unique-constraint columns="name,user_email" name="search_idx" />
      </unique-constraints>

      <lifecycle-callbacks>
      <lifecycle-callback type="prePersist" method="doStuffOnPrePersist"/>
      <lifecycle-callback type="prePersist" method="doOtherStuffOnPrePersistToo"/>
      <lifecycle-callback type="postPersist" method="doStuffOnPostPersist"/>
      </lifecycle-callbacks>

      <id name="id" type="integer" column="id">
      <generator strategy="AUTO"/>
      <sequence-generator sequence-name="tablename_seq" allocation-size="100" initial-value="1" />
      </id>

      <field name="name" column="name" type="string" length="50" nullable="true" unique="true" />
      <field name="email" column="user_email" type="string" column-definition="CHAR(32) NOT NULL" />

      <one-to-one field="address" target-entity="Address" inversed-by="user">
      <cascade><cascade-remove /></cascade>
      <join-column name="address_id" referenced-column-name="id" on-delete="CASCADE" on-update="CASCADE"/>
      </one-to-one>

      <one-to-many field="phonenumbers" target-entity="Phonenumber" mapped-by="user">
      <cascade>
      <cascade-persist/>
      </cascade>
      <order-by>
      <order-by-field name="number" direction="ASC" />
      </order-by>
      </one-to-many>

      <many-to-many field="groups" target-entity="Group">
      <cascade>
      <cascade-all/>
      </cascade>
      <join-table name="cms_users_groups">
      <join-columns>
      <join-column name="user_id" referenced-column-name="id" nullable="false" unique="false" />
      </join-columns>
      <inverse-join-columns>
      <join-column name="group_id" referenced-column-name="id" column-definition="INT NULL" />
      </inverse-join-columns>
      </join-table>
      </many-to-many>

      </entity>

      </doctrine-mapping>
      • [^] # Re: Doctrine2

        Posté par (page perso) . Évalué à 3.

        Si je comprends bien l'exemple, l'équivalent en Rails (ActiveRecord) serait :


        # Le modèle est décrit dans le fichier app/models/user.rb
        class User < ActiveRecord::Base
        # Validations
        validates :email, :uniqueness

        # Lifecycle callbacks
        before_save :do_stuff_on_pre_persist
        before_save :do_another_stuff_on_pre_persist_too
        after_save :do_stuff_on_post_persist

        # Associations
        has_one :address, :dependent => :destroy
        has_many :phone_numbers
        has_ad_belongs_to_many :groups
        end



        # La création de la table SQL se fait avec une migration (fichier db/migrate/_create_users.rb)
        class CreateUsers < ActiveRecord::Migration
        def self.up
        create_table :users do |t|
        t.string :name, :limit => 50, :null => false
        t.string :email, :limit => 32, :null => false
        end

        # Indexes
        add_index :users, [:name, :email], :unique => true
        add_index :users, :name # Cet index est redondant, mais je l'ai gardé car il était dans l'exemple de départ
        add_index :users, :email
        end

        def self.down
        drop_table :users
        end
        end
        • [^] # Re: Doctrine2

          Posté par (page perso) . Évalué à 2.

          Je n'ai pas réussi à mettre en forme les exemples avec templeet. La même chose sur la future version en Rails de LinuxFr.org est visible là : http://alpha.linuxfr.org/users/nono/journaux/essai-coloratio(...)
        • [^] # Re: Doctrine2

          Posté par (page perso) . Évalué à 5.

          J'adore quand on prend un exemple sans regarder la page suivante qui te montre un mapping mais en yaml...Du coup ça parait moins illisible que le xml que tu balances ;)


          Le voilà donc, et, vous en conviendrez, c'est quand même moins dégueux que le xml présenté au dessus (désolé, j'utilise doctrine tous les jours et je me suis jamais paluché une ligne de xml ;), donc je ne pouvais que réagir !) :


          # Doctrine.Tests.ORM.Mapping.User.dcm.yml
          Doctrine\Tests\ORM\Mapping\User:
          type: entity
          table: cms_users
          id:
          id:
          type: integer
          generator:
          strategy: AUTO
          fields:
          name:
          type: string
          length: 50
          oneToOne:
          address:
          targetEntity: Address
          joinColumn:
          name: address_id
          referencedColumnName: id
          oneToMany:
          phonenumbers:
          targetEntity: Phonenumber
          mappedBy: user
          cascade: cascadePersist
          manyToMany:
          groups:
          targetEntity: Group
          joinTable:
          name: cms_users_groups
          joinColumns:
          user_id:
          referencedColumnName: id
          inverseJoinColumns:
          group_id:
          referencedColumnName: id
          lifecycleCallbacks:
          prePersist: [ doStuffOnPrePersist, doOtherStuffOnPrePersistToo ]
          postPersist: [ doStuffOnPostPersist



          (bon j'ai perdu le formatage du yaml au passage par templeet...)
          • [^] # Re: Doctrine2

            Posté par (page perso) . Évalué à 2.

            > J'adore quand on prend un exemple sans regarder la page suivante qui te montre un mapping mais en yaml...

            Effectivement, j'ai pris le premier exemple trouvé sans chercher plus loin.

            Par contre, je suis surpris, on ne retrouve pas les mêmes champs dans les deux exemples. Il semblerait que tout ce qui concerne les indexes, le unique-constraint et les cascades aient disparu de la version YAML.

            Dans tous les cas, je continue de préférer la version Ruby à la meta-description de Doctrine 2 (que le format soit XML ou YAML).
            • [^] # Re: Doctrine2

              Posté par (page perso) . Évalué à 2.

              Les index sont implicites, les contraintes aussi et les cascades aussi. Tu ne défini tout ça que si tu sors du "défaut". Les champs id et les champs de liaison sont indexés, les tables liées subissent un onDelete Cascade etc.

              Faudrait compiler ce yaml par doctrine pour voir si il nous sortirait exactement le même fichier que le xml (je n'ai pas utilisé Doctrine 2, donc je m'avance pas trop, ils ont peut-être fait des choix différents sur les défauts, le côté implicite toussa...).


              (on voit d'ailleurs qu'il y a un cascadePersist de défini en yaml)

              Etant habitué à la syntaxe Doctrine, elle me parait plus lisible que celle de ActiveRecord de Rails (et pas énormément plus verbeuse), mais ce n'est probablement qu'une question d'habitude, et comme tu le dis "les goûts et les couleurs"...Je voulais juste mettre un exemple plus "correct" de la syntaxe de Doctrine pour que la comparaison soit plus fair-play ;)
            • [^] # Re: Doctrine2

              Posté par (page perso) . Évalué à 1.

              Il n'y a pas que XML et YAML de disponible... faut chercher un peu plus loin.

              La plupart des exemples de la documentation reposent sur les docblocks annotations qui reste (avis personnel) le plus lisible et évite de s'éparpiller.

              Voir http://www.doctrine-project.org/docs/orm/2.0/en/reference/an(...)
    • [^] # Re: Doctrine2

      Posté par (page perso) . Évalué à 6.


      affirme la supériorité du langage PHP


      http://bit.ly/eDScUc
      • [^] # Re: Doctrine2

        Posté par (page perso) . Évalué à 4.

        La phrase non tronquée devait être :
        La supériorité de PHP comme générateur aléatoire de résultat. :P
    • [^] # Re: Doctrine2

      Posté par (page perso) . Évalué à 5.

      Windows c'est largement mieux que Linux parce qu'il y a Visio pour faire des schémas et en plus on peut faire des scripts en Visual Basic.

      Bah oui, quitte à dire des conneries...
    • [^] # Re: Doctrine2

      Posté par . Évalué à 3.

      T'as mal réglé ton iPot, tu postes un jeudi là!
    • [^] # Re: Doctrine2

      Posté par . Évalué à 2.

      Si on a le droit de troller, je préfère de loin JPA ou hybernate qui me permet de me contenter de coder des classes décorées pour avoir mon modèle de donnée comme je le souhaite. En plus lié à JSF ça déchire tout (sauf probablement niveau performance) et ça permet de faire du 3 tières ce que je trouve plus logique.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Doctrine2

        Posté par . Évalué à 1.

        Ce que tu peux faire aussi avec Doctrine 2 :

        <?php

        namespace Application\HonBundle\Entity;

        /**
        * @orm:Entity
        */
        class Statistics
        {

        /**
        * @orm:Id
        * @orm:Column(type="integer")
        * @orm:GeneratedValue(strategy="IDENTITY")
        */
        protected $id;

        /**
        * @orm:OneToOne(targetEntity="Player")
        */
        protected $player;

        /**
        * @orm:Column(type="integer")
        */
        protected $psr;

        }
    • [^] # Re: Doctrine2

      Posté par (page perso) . Évalué à 2.

      Gros troll va, tu m'attise :)

      Pour ma part, je suis un fervent dépendant de SQLAlchemy.

      Pourquoi décrire en XML, YAML, etc. et non directement en python ? C'est drôlement plus flexible !


      http://www.sqlalchemy.org/docs/05/reference/ext/declarative.(...)
  • # MySQL HandlerSocket

    Posté par (page perso) . Évalué à 3.

    C'est vrai que c'est le seul projet qui n'a pas bénéficié du tampon Oracle. Tout les autres projets sont renommés progressivement à l'occasion de la sortie d'une release majeure.

    Mais au delà de ce troll, il y a tout de même la réponse de MySQL AB aux serveurs dictionnaires (clé-valeur) qu'est HandlerSocket. Le principe est de contourner le parser de requête SQL pour directement servir les données en fonction d'une clé. Je n'ai pas encore eu l'occasion de tester, mais c'est une réponse intéressante de la part de MySQL aux jeunes bases de données servant des documents.

    Et le compromis entre fonctionnalité et performance fait reculer le moment à partir duquel on va s'orienter vers un foutoir tel que MongoDB ou tout autre base d'objets.

    Pour les plus curieux : http://planet.mysql.com/?tag_search=9762
    • [^] # Re: MySQL HandlerSocket

      Posté par . Évalué à 3.

      > Mais au delà de ce troll, il y a tout de même la réponse de MySQL AB aux serveurs dictionnaires (clé-valeur) qu'est HandlerSocket.

      HandlerSocket est très chouette (de fameuses performances, un kv-store automatiquement à jour - ou presque - par rapport aux données accédées de façon SQL/relationelle, ...), mais rendons à César ce qui est à César :

      - MySQL A.B. n'est plus, désormais devenu Oracle Corporation
      - HandlerSocket n'est pas l'oeuvre d'Oracle (ou feu MySQL A.B.) mais de la société japonaise DeNA.

      On ne peux donc pas vraiment dire que ce soit "une réponse de MySQL".

      > Et le compromis entre fonctionnalité et performance fait reculer le moment à partir duquel on va s'orienter vers un foutoir tel que MongoDB ou tout autre base d'objets.

      Il semblerai qu'HandlerSocket ai déjà des perfs en lecture généralement supérieures à MongoDB (qui n'est pourtant pas lent). Mais il me semble que l'intéret d'outils comme CoucheDB, MongoDB, Riak & co réside justement plutôt dans les fonctionalités originales qu'ils offrent (mise en oeuvre de MapReduce par ex.) et dans l'aisance qu'ils apportent pour ceux qui veulent ou doivent partitionner le travail sur de nombreuses machines ("scale out" grace au partitionnement automatique, à la résolution de conflits rationelle, ce genre de choses).
  • # vimgolf

    Posté par . Évalué à 3.

    Super vimgolf !

    C'est ça que j'aurais aimé découvrir quand j'étais plus jeune et plus facilement dissipé plutôt que l'austère vimtutor.

    Mais par contre, dites moi que j'ai mal compris. Il est possible de participer sans avoir un compte touitteur hein ?

    Dites ?
    • [^] # Re: vimgolf

      Posté par . Évalué à 4.

      Bon la question a déjà été posée. Putain de proxy d'entreprise qui m'indique qu'il n'y a pas de commentaires alors qu'il y en a déjà 20.

      @#%!*


      Vous pouvez moinsser ces commentaires.
      • [^] # Re: vimgolf

        Posté par (page perso) . Évalué à 3.

        tu peux essayer de demander à ssig^Wl'admin sys de passer linuxfr en https sur la liste blanche :) (ça servira aussi à d'autres)

Suivre le flux des commentaires

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