Estoy tratando de actualizar la gema de ActiveRecord a la última versión 3.1.0 y viendo surgir muchas excepciones, creo que se debe a la forma en que manejamos varias bases de datos.bases de datos múltiples de ActiveRecord 3.1.0
Para cada una de nuestras bases de datos especificamos una clase base separada que hereda de ActiveRecord::Base
, y llama al establish_connection
allí. No hay relaciones entre bases de datos. Esto ha funcionado bien para nosotros hasta ahora.
Al haber actualizado a ActiveRecord 3.1.0 veo que falla con una excepción ActiveRecord::ConnectionNotEstablished
, al atravesar relaciones (es decir, extraerá con éxito una sola entidad o conjunto de ellas de la base de datos, pero falla al navegar a una clase).
La línea superior del backtrace es C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:410:in 'retrieve_connection'
, así que profundicé un poco. El método se define como sigue:
def retrieve_connection(klass) #:nodoc:
pool = retrieve_connection_pool(klass)
(pool && pool.connection) or raise ConnectionNotEstablished
end
Mi prueba simple (puts Customer.first.address
) llama retrieve_connection
3 veces. Dos veces con Customer
como el parámetro klass
, y una vez con ActiveRecord::Base
como el parámetro - que es cuando falla como establish_connection
no se ha llamado para ActiveRecord::Base
.
A la pregunta real, entonces, ¿hay una nueva forma recomendada de manejar conexiones de bases de datos múltiples en ActiveRecord? Si es así, ¿qué es?
Si no, ¿qué podría estar causando este problema?
Gracias por eso, no he tenido tiempo de probarlo pero parece una buena solución. Vuelva y avísenos si encuentra una mejor manera ... –
Nos hemos encontrado con el mismo problema y nos gustaría encontrar una solución mejor. Gracias por la ayuda, sin embargo. ¡Al menos ahora también estamos desbloqueados! – jasonkarns
Me metí en este problema yo mismo (activerecord 3.1.3) y resolví el problema como se sugirió. Estoy de acuerdo en que una mejor solución sería más ideal. –