ActiveRecord - Multiples Bases de datos

Durante un seminario acerca de Rails, alguien me pregunto sobre la posibilidad de acceder a una fuente de datos que fuera la configurada por defecto en el entorno en el que nos encontremos, a saber, desarrollo, test y producción. Tengo que confesar que la pregunta me cogió un poco por sorpresa, pero pensando en ello, y con la confianza que te dan las buenas ideas que se desprenden de todo lo que rodea a Rails, supusimos entre todos que si que se podría. Efectivamente, asi es. De hecho, es realmente sencillo.

Tendremos que llamar al método establish_connection del modelo que apunte a la BD externa con una sintaxis como esta.

Class_name.establish_connection(
:adapter => "mysql",
:host => "host_name",
:username => "username",
:password => "password",
:database => "db_name"
)

De este modo, tanto esta clase, como el resto de subclases harán uso de la nueva conexión. El resto de clases del modelo seguirán usando la BD configurada por defecto en el archivo database.yml

Active Record = Join Tables

En uno de los primeros POSTs de este blog, hablaba de las relaciones entre tablas a través de los modelos de ActiveRecord e intentaba (conseguía?)explicar un modo para entender como definir correctamente estas relaciones. Me gustaría ampliar un poco esto para analizar una de las relaciones que creo que no he tratado correctamente, las relaciones N a N a través de Join tables.

Estas relaciones se dan cuando tenemos dos tablas relacionadas entre si a través de una tercera tabla. En esta tabla, se suele sustituir la clave primaria por la unión de los índices de las dos tablas relacionadas, si bien esto no es obligatorio.

Rails permite definir estas relaciones de una manera muy sencilla usando en ambos modelos la relación has_and_belongs_to_many :tabla (vaya nombrecito). Usando esta sencilla fórmula, seremos capaces de acceder desde un objeto de uno de los modelos a la lista de elementos del otro modelo de una forma muy sencilla. Por ejemplo, si relacionamos Authors y Articles a través de la Join Table Publication, podremos hacer algo así.

autor = Author.find(:first)
lista_articulos = autor.articles

En lista_articulos tendremos un array de objetos Article que se han asociado a Author a través de la tabla Publication. Tendremos que seguir ciertas convenciones que rails nos indica como que el nombre físico de la join table este compuesto por los nombres de las tablas enlazadas en minúscula y en orden alfabético. Si queréis ver la especificación, visitad el API. Facil no???

Pero hay un problema. Imaginemos que esta tabla Publication tiene campos adicionales que no son los índices de las tablas referenciadas. Rails no nos pone ninguna pega para acceder a esta información. De hecho, la incluye en el array que hemos obtenido anteriormente. El problema es que estos campos son de solo lectura. No se pueden modificar. La aproximación que se tomaba era la utilización de delete para borrar una entrada antigua y del método push_with_attributes(object, attributes) para introducir una tupla nueva en la join table. PERO ESTE METODO ESTA DEPRECATED. NO LO USEIS.

Afortunadamente, este problema ya esta resuelto. El truco (no es un truco, pero vaya) es usar una doble relación has_many en ambas tablas a relacionar usando el modificador :through. Ah, y creando un nuevo modelo que nos identifique la join table. Esto es muchísimo mejor, ya que recuperamos toda la funcionalidad que nos proporciona el tener una tabla identificada por un modelo. También eliminamos la necesidad de llamar a la tabla con nombres raros (autor_articulo en el caso anterior)

Bueno, como definiríamos esto en la relación anterior???? Marchando.

class Author << ActiveRecord::Base
has_many :publications
has_many :articles, :through => :publications
end

class Publication << ActiveRecord::Base
belongs_to :author
belongs_to :article
end

class Article<< ActiveRecord::Base
has_many :authors
has_many :authors, :through => :publications
end

Que os parece??? tenemos ahora acceso a tooooodos los métodos de inserción, etc... De la tabla Publication y podemos trabajar de un modo mucho más sencillo.

Active Record find

Actualmente me encuentro desarrollando una aplicación WEB que dispone de un API REST y una parte estándard. A la hora de desarrollar las consultas a los modelos, me he encontrado con que algunas de estas son muy complejas y tiendo a pensarlas en SQL directamente, ya que es un lenguaje que da un gran rendimiento y flexibilidad.

ActiveRecord::Base nos proporciona dos métodos para realizar estas consultas, find y find_by_sql. En el caso del segundo la opción está clara: insertar directamente el SQL que he pensado para obtener solo lo que yo quiero obtener y con el formato que yo necesito. En el caso del primero, solo con echar un vistazo al API podemos ver que tiene un gran número de posibilidades, parámetros, etc.. que lo convierten en una opción muy poderosa para realizar las consultas. Asi pues, me surge una duda ¿Cual de ellas usar?

Esta pregunta, que en principio parece muy sencilla, no lo es tanto. Si controlas SQL tenderás a hacer uso de find_by_sql ya que te abstraeras de aprender las opciones y posibilidades de ActiveRecord y trabajarás con algo conocido. Pero precisamente esto es algo que no deberíamos hacer. Bajo mi punto de vista, tendríamos que usar las ventajas que nos da Rails evitando usar SQL directamente.

Diseñamos la BD, definimos los modelos de las tablas, declaramos las relaciones entre ellos. CONTROLAMOS la estructura de nuestros datos. Imaginemos que tenemos una tabla Articles y otra tabla Tags. Definimos una relación n-to-n con sendas directivas :has_and_belongs_to. Bien, pues en el caso en que queramos obtener todas las tags de un artículo, podemos bien escribir un SQL que obtenga la información de las distintas tablas o podemos dejar hacer a ActiveRecord, ya que por el hecho de tener esta relación, es capaz de proporcionarnos esta información automáticamente con el siguiente código.

article = Article.find(article_id)
article.tags.each do |tag|
puts tag.tag_name
end

Mantenemos el código sencillo. Usamos los convencionalimos de Rails. Resulta extremadamente sencillo de interpretar. EVITAMOS MEZCLAR LENGUAJES.

AOP en Rails???? Marchando!!!!!!!

Observers. Si conoces como funciona AOP te vas a maravillar con lo sencillo que va a ser añadir control de aspectos a nuestras clases Model en Rails. De echo, si lo pensamos un momento es el punto más obvio del modelo Rails en el que añadir esta funcionalidad. Nos va a permitir añadir control a los puntos de entrada y salida de las operaciones CRUD que nos proporciona ActiveRecord::Base, es decir, new, create, update, delete, save.

Lo que nos propone ActiveRecord::Observer es el poder crear metodos que se ejecuten antes o después de las invocaciones a cada uno de estos métodos. La forma es muy sencilla. Estos son los pasos para hacer un log para cada operación de guardado. Haremos un pre-log y un post-log.

1. Creamos una clase que herede de ActiveRecord::Observer y la nombraremos con el nombre del Modelo a observar seguido de Observer, es decir, si nuestro modelo es Shop la llamamos ShopObserver.
   
2. Guardamos el archivo en la carpeta app\model con el nombre shop_observer.rb
3. definimos un método before_save en el que ponemos la funcionalidad a ejecutar ANTES de guardar. En nuestro caso, el log.
   
4. definimos un método after_save donde incluimos funcionalidad para DESPUES de guardar.
5. Editamos el archivo config/environment.rb modificando la entrada config.active_record.observers = :shop_observer

El codigo fuente final

class ShopObserver < ActiveRecord::Observer def before_save(a_shop) a_shop.logger.info("PRE-LOG - Shop name = #{a_shop.name}") end def after_save(a_shop) a_shop.logger.info("POST-LOG - Shop name = #{a_shop.name}") end end Y ya esta todo. Ahora podemos ejecutar la consola del entorno con ruby script/console para testear lo que hemos creado. Si ejecutamos
shop = Shop.new(:name=>"ebay")
shop.save

vamos a ver que el archivo development.log va a contener dos entradas de log ejecutadas antes y después de llamar al método save.

Yo estoy cada vez más encantado con la funcionalidad que me proporciona este framework DE SERIE, y sin necesidad de añadirle plugins o librerías externas.