En mi entorno, los servidores de implementación tienen gran parte de la información de conexión que se encuentra en la base de datos.yml. Es decir, saben si son servidores de desarrollo, prueba o producción, y conocen su respectiva información de conexión de base de datos.

Puedo encapsular esta información en una clase de Servidor, por ejemplo, para poder recuperar la información:

Server["environment"] #=> production
Server["db_host"] #=> db5.example.com
Server["db_password"] #=> [a decrypted password]

y así. Me gustaría implementar una aplicación Rails y hacer que se configure automáticamente en función de la configuración del servidor. ¿Cuál es la mejor manera de hacer esto?

Una forma de hacerlo es Erb en mi database.yml:

<%= Server["environment"] %>: 
  adapter: oracle_enhanced
  host: <%= Server["db_host"] %>
  username: db_user 
  password: <%= Server["password"] %>

No estoy muy emocionado de hacerlo de esta manera, pero funcionaría. En este caso, ¿dónde pondría el 'server.rb' que define la clase de Servidor? ¿Lo requiero aquí en el yml? app / initializers se carga después de que ActiveRecord carga database.yml.

Otra posible solución es anular de alguna manera el inicializador de la base de datos de railties:

# File railties/lib/initializer.rb, line 903
def database_configuration
  require 'erb'
  YAML::load(ERB.new(IO.read(database_configuration_file)).result)
end

Lo anterior solo se llama si: active_record se define en config.frameworks. No estoy seguro de cómo anularía esto lo suficientemente temprano en la secuencia de inicio de Rails.

Quizás una tercera opción eseliminar : active_record de config.frameworks, y luego crea la conexión más tarde, ¿por ejemplo en los inicializadores de la aplicación? Me temo que esto puede tener muchos efectos secundarios no deseados.

estoyesperando que hay algo simple y obvio que no he encontrado, como una función ActiveRecord que me permite optar por no salir de database.yml y proporcionar una configuración alternativa mediante programación.