Je comprends que c'est un remplacement d'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 conduira-t-il à des requêtes SQL plus efficaces?
sera-t-il compatible avec toutes les principales bases de données? - Je suppose que ce sera le cas.
sera-t-il plus facile / plus difficile à utiliser avec les procédures stockées?
Réponses:
Qu'est-ce que Arel dans Rails 3.0?
C'est un modèle objet pour une algèbre d'opérateurs de requêtes relationnelles.
Je comprends qu'il s'agit d'un remplacement d'ActiveRecord
Non, ça ne l'est pas. C'est un remplacement pour les requêtes SQL artisanales dans des chaînes. C'est une couche de requête courante qui sous - tend ActiveRecord, mais elle peut également être utilisée comme sous-jacent pour DataMapper, par exemple.
Si c'est un remplacement pour quoi que ce soit, c'est un remplacement pour Ambition. Ou, vous pouvez le considérer comme une version Ruby des opérateurs de requête standard LINQ ou SQLAlchemy de Python. (En fait, l'auteur cite explicitement LINQ et SQLAlchemy comme inspirations.)
Ou, vous pouvez le voir comme un remplacement de l' named_scopeart. 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 sous forme d'objets au lieu de chaînes. Construire 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 création d'un modèle d'objet approprié pour un système comptable au lieu d'utiliser des chaînes pour tout vous donne.
Un autre gros avantage est qu'ARel implémente une algèbre réelle des opérateurs de requête. En d'autres termes, ARel connaît les règles mathématiques pour construire et composer des requêtes. Si vous concaténez deux chaînes, dont chacune contient une requête SQL valide, le résultat ne sera probablement pas une requête SQL valide. Ou, pire encore, il 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. Cela ne peut jamais arriver avec ARel. (C'est ce que signifie l'article auquel je renvoie ci-dessous avec "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 créer 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 principales bases de données? - Je suppose que ce sera le cas.
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, voyez LINQ ou Ambition comme exemples: les deux peuvent interroger SQL, LDAP, ActiveResource, CouchDB, Amazon, Google,… le tout avec la même syntaxe.
Peut-être que la meilleure discussion sur ce qu'est ARel et pourquoi Nick Kallen a écrit est l'article bien nommé Why Arel? par Nick Kallen lui-même. Remarque: l'article contient un jargon mathématique et informatique doux, mais c'est exactement le but: ARel a des bases solides en mathématiques et en informatique, ce sont ces bases qui lui confèrent ses propriétés puissantes.
ARel, est malheureusement directement lié à la génération de SQL et n'est donc pas adapté aux besoins de DataMapper.
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.
En fait, j'ai commencé une série de vidéos sur ActiveRelation.
Le premier tutoriel général peut être consulté sur http://Innovative-Studios.com/#pilot