Entiendo que es un reemplazo de ActiveRecord y que usa objetos en lugar de consultas.
Pero...
porque es esto mejor
¿Será "más fácil" crear objetos / consultas?
¿conducirá a consultas SQL más eficientes?
¿Será compatible con las principales bases de datos? - Asumo que lo hará.
¿Será más fácil / difícil de usar con procedimientos almacenados?
¿Qué es exactamente Arel en Rails 3.0?
Es un modelo de objetos para un álgebra de operadores de consultas relacionales.
Entiendo que es un reemplazo de ActiveRecord
No, no lo es. Es un reemplazo para la elaboración manual de consultas SQL en cadenas. Es una capa de consulta común que subyace a ActiveRecord, pero también se puede utilizar como base para DataMapper, por ejemplo.
Si es un reemplazo de algo, es un reemplazo de Ambition. O puede pensar en ello como una versión Ruby de los operadores de consulta estándar LINQ o SQLAlchemy de Python. (De hecho, el autor cita explícitamente tanto LINQ como SQLAlchemy como inspiraciones).
O puede verlo como un reemplazo para named_scopes. De hecho, ARel es prácticamente la realización de la idea de que "cada consulta es un named_scope". Y, qué sepas: ambos fueron escritos por el mismo tipo.
y que utiliza objetos en lugar de consultas.
No, utiliza objetos como consultas.
porque es esto mejor
Ruby es un lenguaje orientado a objetos, no un lenguaje orientado a cadenas. Solo por esa razón , tiene sentido representar las consultas como objetos en lugar de cadenas. La creación de un modelo de objetos adecuado para las consultas en lugar de utilizar cadenas para todo le ofrece prácticamente los mismos beneficios que la creación de un modelo de objetos adecuado para un sistema de contabilidad en lugar de utilizar cadenas para todo.
Otra gran ventaja es que ARel implementa un álgebra real de operadores de consulta. En otras palabras, ARel conoce las reglas matemáticas para construir y redactar consultas. Si concatenas dos cadenas, cada una de las cuales contiene una consulta SQL válida, es probable que el resultado no sea una consulta SQL válida. O, peor aún, es una consulta SQL válida, pero una que no tiene sentido, o que hace algo totalmente diferente de lo que crees que hace. Esto nunca puede suceder con ARel. (Esto es lo que significa el artículo que enlazo a continuación con "composición cerrada").
¿Será "más fácil" crear objetos / consultas?
Si. Por ejemplo, como mencioné anteriormente, es mucho más fácil construir consultas más complejas a partir de partes más simples.
¿conducirá a consultas SQL más eficientes?
Si. El hecho de que ARel tenga un modelo de objetos adecuado para las consultas significa que puede realizar optimizaciones en esas consultas mucho antes de generar una consulta SQL real.
¿Será compatible con las principales bases de datos? - Asumo que lo hará.
Si. De hecho, siempre hablé de SQL arriba, pero en realidad un álgebra de consultas relacionales puede generar consultas para casi todo. Nuevamente, vea LINQ o Ambition como ejemplos: ambos pueden consultar SQL, LDAP, ActiveResource, CouchDB, Amazon, Google,… todos con la misma sintaxis.
Quizás la mejor discusión sobre qué es ARel y por qué escribió Nick Kallen es el artículo acertadamente llamado ¿Por qué Arel? por el propio Nick Kallen . Nota: el artículo contiene un poco de jerga matemática e informática, pero ese es exactamente el punto: ARel tiene unas bases sólidas en matemáticas e informática, esas bases son las que le dan sus poderosas propiedades.
ARel, desafortunadamente, está directamente vinculado a la generación de SQL y, por lo tanto, no es adecuado para las necesidades de DataMapper.
La forma en que lo diría es que ARel es un modelo de consulta explícito para ActiveRecord que genera y optimiza consultas SQL para RDBMS.
DataMapper, por otro lado, es un mapeador genuino de datos y ya puede interactuar con almacenes de datos no relacionales. En el futuro, es probable que DataMapper incluya una biblioteca separada llamada Veritas, que está destinada a proporcionar funcionalidad relacional a los datos provenientes de CUALQUIER almacén de datos, no solo de RDBMS.
fuente
Arel en Rails 3 crea objetos de relación donde la base de datos no se consulta hasta que la necesita. Mucho más eficiente.
También es más natural (una vez que te acostumbras), que es realmente la gran fortaleza de Rails.
fuente
De hecho, he comenzado una serie de videos sobre ActiveRelation.
El primer tutorial general se puede ver en http://Innovative-Studios.com/#pilot
fuente