En quoi consiste exactement Arel dans Rails 3.0?
Je comprends qu'il s'agit d'un remplacement pour ActiveRecord et qu'il utilise des objets au lieu de requêtes.
Mais...
pourquoi est-ce mieux?
les objets/requêtes seront-ils "plus faciles" à créer?
cela mènera-t-il à des requêtes SQL plus efficaces?
sera-t-il compatible avec toutes les bases de données principales? - Je suppose que oui.
sera-t-il plus facile/plus difficile à utiliser avec les procédures stockées?
En quoi consiste exactement Arel dans Rails 3.0?
Il s'agit d'un modèle d'objet pour une algèbre d'opérateurs de requêtes relationnelles.
Je comprends qu'il s'agit d'un remplacement pour ActiveRecord
Non, ça ne l'est pas. Il remplace les requêtes SQL artisanales dans les chaînes. Il s'agit d'une couche de requête commune qui sous-tend ActiveRecord, mais elle peut également être utilisée comme support pour DataMapper, par exemple.
Si c'est un remplacement pour quelque chose, c'est un remplacement pour Ambition. Ou, vous pouvez le considérer comme une Ruby des opérateurs de requête standard LINQ ou SQLAlchemy de Python. (En fait, l'auteur cite explicitement LINQ et SQLAlchemy comme sources d'inspiration).
Ou, vous pouvez le voir en remplacement de named_scopes. En fait, ARel est à peu près la réalisation de l'idée que "chaque requête est un named_scope ". Et, whaddayaknow: les deux ont été écrits par le même gars.
et qu'il utilise des objets au lieu de requêtes.
Non, il utilise des objets comme requêtes .
pourquoi est-ce mieux?
Ruby est un langage orienté objet, pas un langage orienté chaîne. Pour cette seule raison , il est logique de représenter les requêtes comme des objets au lieu de chaînes. La construction d'un modèle d'objet approprié pour les requêtes au lieu d'utiliser des chaînes pour tout vous offre à peu près les mêmes avantages que la construction d'un modèle d'objet approprié pour un système de comptabilité au lieu d'utiliser des chaînes pour tout.
Un autre gros avantage est que ARel implémente une algèbre réelle d'opérateurs de requête. En d'autres termes, ARel connaît les règles mathématiques pour la construction et la composition de requêtes. Si vous concaténez deux chaînes, chacune contenant une requête SQL valide, le résultat ne sera probablement pas une requête SQL valide. Ou, pire encore, c'est est une requête SQL valide, mais qui n'a pas de sens, ou qui fait quelque chose de totalement différent de ce que vous pensez Est-ce que. Cela ne peut jamais se produire avec ARel. (C'est ce que l'article auquel je renvoie ci-dessous signifie "fermé sous composition".)
les objets/requêtes seront-ils "plus faciles" à créer?
Oui. Par exemple, comme je l'ai mentionné ci-dessus, il est beaucoup plus facile de construire des requêtes plus complexes à partir de parties plus simples.
cela conduira-t-il à des requêtes SQL plus efficaces?
Oui. Le fait qu'ARel dispose d'un modèle d'objet approprié pour les requêtes signifie qu'il peut effectuer des optimisations sur ces requêtes bien avant de générer une requête SQL réelle.
sera-t-il compatible avec toutes les bases de données principales? - Je suppose que oui.
Oui. En fait, j'ai toujours parlé de SQL ci-dessus, mais en fait, une algèbre de requête relationnelle peut générer des requêtes pour à peu près tout. Encore une fois, voir LINQ ou Ambition comme exemples: les deux peuvent interroger SQL, LDAP, ActiveResource, CouchDB, Amazon, Google,… tous avec la même syntaxe.
Peut-être la meilleure discussion sur ce qu'est ARel et pourquoi Nick Kallen a écrit est l'article bien nommé Pourquoi Arel? par Nick Kallen lui-même. Remarque: l'article contient un léger jargon mathématique et informatique, mais c'est exactement le point: ARel a des bases solides en mathématiques et en informatique, ces bases lui donnent ses puissantes propriétés.
ARel, est malheureusement directement lié à la génération de SQL et ne convient donc pas aux besoins de DataMapper.
La façon dont je dirais que ARel est un modèle de requête explicite pour ActiveRecord qui génère et optimise les requêtes SQL pour les SGBDR.
DataMapper, quant à lui, est un véritable mappeur de données et peut déjà s'interfacer avec des magasins de données non relationnels. À l'avenir, DataMapper inclura probablement une bibliothèque distincte appelée Veritas, qui est destinée à fournir des fonctionnalités relationnelles aux données provenant de N'IMPORTE QUEL magasin de données, pas seulement des SGBDR.
Arel in Rails 3 crée des objets de relation où la base de données n'est pas interrogée jusqu'à ce que vous en ayez besoin. Beaucoup plus efficace.
C'est aussi plus naturel (une fois que vous vous y êtes habitué), ce qui est vraiment la grande force de Rails.
En fait, j'ai commencé une série de vidéos sur ActiveRelation.
Le premier didacticiel général peut être consulté sur http://Innovative-Studios.com/#pilot