DataMapper 1.0

Posté par (page perso) . Modéré par Mouns.
Tags :
18
10
juin
2010
Ruby
DataMapper est une bibliothèque en Ruby qui vous permet de manipuler des données dans des bases de données sous forme d'objets Ruby (c.-à-d., c'est un ORM). Sous licence MIT, il vient de sortir en version 1.0, grâce au travail de 66 contributeurs.

Dans le monde Ruby, l'utilisation d'ORM est devenue une pratique courante sous l'influence de Ruby on Rails. ActiveRecord, l'ORM de Ruby on Rails, est ainsi très utilisé mais il ne convient pas à tout le monde. Les développeurs de Ruby on Rails ont des avis très tranchés sur certains points et, notamment, cherchent toujours à répondre aux 20% de cas d'utilisation qui couvrent 80% des besoins. Mais certaines personnes ont des besoins plus particuliers : c'est ce qui est arrivé aux développeurs de DataMapper.

L'équipe de DataMapper a ainsi voulu fournir une bibliothèque plus complète qu'ActiveRecord. On peut ainsi citer les points forts suivants :
  • Support de nombreuses bases de données, aussi bien relationnelles que NoSQL, mais également de fichiers YAML et d'interfaces REST ;
  • Migrations automatiques : on écrit les classes Ruby, puis on demande à DataMapper de créer les tables correspondantes dans la base de données ;
  • Unicité des objets : une ligne dans la base de données correspond à un objet ;
  • Approche modulaire : on choisit les fonctionnalités dont on a vraiment besoin ;
  • Réduction du nombre de requêtes : DataMapper ne fait les requêtes qu'au moment où vous avez vraiment besoin d'y accéder (Lazyness can be a virtue) et précharge les objets quand vous itérez sur des collections (Strategic eager loading) ;
  • Intégration plus souple à des projets Ruby existants.


La version 3 de Ruby on Rails devrait sortir d'ici quelques semaines et va notamment permettre de remplacer facilement ActiveRecord par un ORM dans les projets Rails.
Saluons donc l'arrivée de DataMapper 1.0 qui va permettre de couvrir des scénarios complexes pour des projets Rails ou autres.
  • # NoSQL

    Posté par . Évalué à 6.

    Ayant été élevé au SQL et aux bases de données relationnelles, j'ai clairement du mal à imaginer comment on peut faire différemment.

    J'ai déjà essayé de comprendre via quelques articles par-ci par-là mais à chque fois, non, désolé... y a pas comprenage.

    Donc si quelqu'un peut expliquer les fondamentaux, ou simplement donner un lien vers un article bien didactique sur le sujet, je suis preneur !
    • [^] # Re: NoSQL

      Posté par . Évalué à 2.

      De quoi parles-tu justement ? NoSQL ? ORM ?
    • [^] # Re: NoSQL

      Posté par . Évalué à 5.

      De mon point de vue, NoSQL c'est juste un buzz-word pour regrouper ensemble toutes les technos de gestion de bases de données qui n'implémentent pas SQL, mettent de côté toutes les contraintes du type ACID, intégrité, etc; et en profitent pour exceller dans d'autres domaines (performances brutes, clusturing, etc). C'est fait pour répondre à des besoins très spécifiques, chaque solution à ses spécificités, et c'est pas fait pour remplacer entièrement un SGDB classique.
  • # A force de coller du SQL de partout

    Posté par . Évalué à 0.

    Le SQL c'est bien , voui mais si on en colle de partout comme le font certain éditeur cela devient très lourd (typiquement de l'objet mappé en relationnel)

    Typiquement la modification d'un document type mémo ou devis peut être géré avec du No SQL et différente version du document, quitte a les reunifier aprés.

    Par contre certain cas comme la gestion de stock dans un environnement multi user je vois pas comment on peu faire sans SQL

    Les quelques base de données objets que j'ai vu étaient trop limités (style eyedb ou zobd)

    ya t il des base de données OBJETS que vous connaissez qui tiennent la route ?

    A+
    chris
    • [^] # Re: A force de coller du SQL de partout

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

      > Par contre certain cas comme la gestion de stock dans un environnement multi user je vois pas comment on peu faire sans SQL

      Je ne vois pas ce qui empêcherait de le faire avec une base de données documents comme MongoDB ou un stockage de type clé-valeur comme Redis.

      > ya t il des base de données OBJETS que vous connaissez qui tiennent la route ?

      Des bases objets, non, mais des bases de données documents, oui. Je pense notamment à MongoDB : http://www.mongodb.org/ .
      • [^] # Re: A force de coller du SQL de partout

        Posté par . Évalué à 2.

        Tiens marrant moi je vois pas comment on peu faire cela avec MongoDB.

        Dans un environnement multi utilisateur de gestion la cohérence des informations est vitale
        ainsi si la base indique un stock de 100 produits, le logiciel ne doit pas permettre le destockage (donc la generation de bon de livraison) de plus de 100 quantités.
        sachant que plusieurs personnes vont demander une affectation en même temps et la le sigle ACID pour ce genre de transaction prend toute sont importance ...

        A = Atomique
        C = Cohérente
        I = Isolée
        D = durable

        pour cela il faut etre le seul a modifier un enreg et donc poser un lock/verrou, mais il faut aussi prévenir les copains que cet enreg est verrouillé ...

        Je n'ai pas trouvé comment on pouvait poser un lock sur un enregistrement mongodb hors tout est la apparemment ce style de base est fait pour gérer des versions et stocker les modifications
        ce qui est difficile par contre en base relationnelle

        Je vois plutot mongodb comme complementaire a mysql / postgresql

        A+
        chris
        • [^] # Re: A force de coller du SQL de partout

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

          > pour cela il faut etre le seul a modifier un enreg et donc poser un lock/verrou, mais il faut aussi prévenir les copains que cet enreg est verrouillé ...

          Il faut effectivement être le seul à modifier un document, mais je ne vois pas pourquoi il faudrait poser un verrou. MongoDB supporte les opérations atomiques [http://www.mongodb.org/display/DOCS/Atomic+Operations].

          La contrainte que MongoDB relâche est la durabilité (D). Bien que cette contrainte soit importante en théorie, je ne suis pas du tout convaincu que cela apport beaucoup en pratique. Les bases de données ne plantent quasiment jamais, les problèmes sont généralement d'origine matériel. Du coup, si on a un seul serveur, et que celui-ci lâche, il faudra de toute manière repartir de la dernière sauvegarde.

          > apparemment ce style de base est fait pour gérer des versions et stocker les modifications

          Tu ne parles pas de CouchDB là ?
          • [^] # Re: A force de coller du SQL de partout

            Posté par . Évalué à 1.

            Oui apparemment mongoDB peut le faire mais ne garanti rien du tout
            il ne veulent pas prendre en compte les locks exclusif et ainsi ils évitent la gestion des deadlocks ou verrou mortels

            Donc si tu as 100 user qui veulent réserver le même billet d'avions ou le même appart en location et qu'il en reste plus qu'un ... en stock

            Par contre tout a ete mis en oeuvre pour gerer plusieurs versions
            ainsi je peu avoir une version du document toi aussi , je valide mes modifs , toi aussi
            et tout est écrit, reste plus qu'a faire un merge de nos modifications respective.

            En transactionnel :

            je veux etre le seul a modifer le stock de (l'appart/ place d'avion/ produit ..)
            begin
            select .... from .... for update nowait;
            si c'est ok
            update ... set ...
            commit (et c'est dans la boite)
            sinon
            Enreg verrouille reessayer plus tard svp
            rollback
            en gros ...

            et en theorie je n'ai pas douze personnes sur le meme siege dans un avion
            ni 6 famille dans le meme appart pour la meme periode et pas de stock farfelu :)
            mais en theorie seulement ....
    • [^] # Re: A force de coller du SQL de partout

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

      A une époque, il y avait O2, mais je ne sais pas ce qu'il est devenu...

      http://circe.univ-fcomte.fr/Marie-France-Lasalle/o2/COURSHTM(...)

Suivre le flux des commentaires

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