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.
Aller plus loin
- DataMapper (14 clics)
- Annonce de la version 1.0 (2 clics)
- Présentation de DataMapper 1.0 lors de la RailsConf (2 clics)
# NoSQL
Posté par gUI (Mastodon) . Évalué à 6.
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 !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: NoSQL
Posté par jhc_ . Évalué à 2.
[^] # Re: NoSQL
Posté par __o . Évalué à 5.
[^] # Re: NoSQL
Posté par Bruno Michel (site web personnel) . Évalué à 1.
« Textuellement, NoSQL est l'abréviation de Not only SQL, pas seulement SQL. »
# A force de coller du SQL de partout
Posté par Christophe B. (site web personnel) . Évalué à 0.
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 Bruno Michel (site web personnel) . Évalué à 2.
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 Christophe B. (site web personnel) . Évalué à 2.
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 Bruno Michel (site web personnel) . Évalué à 2.
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 Christophe B. (site web personnel) . Évalué à 1.
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 lolop (site web personnel) . Évalué à 2.
http://circe.univ-fcomte.fr/Marie-France-Lasalle/o2/COURSHTM(...)
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.