ruby-on-rails - generate - ruby on rails env

Estrategias para anular Database.yml?

Question

En mi entorno, los servidores de implementación tienen mucha de la información de conexión que está en el database.yml. Es decir, saben si son servidores de desarrollo, prueba o producción, y conocen su respectiva información de conexión a la base de datos.

Puedo encapsular esta información en una clase de servidor, por ejemplo, para que pueda 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 configurarla 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 del Servidor? ¿Lo requiere aquí en el yml? la aplicación / inicializadores se carga después de que ActiveRecord cargue database.yml.

Otra posible solución es anular de algún modo 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 se llama solo si: active_record se define en config.frameworks. No estoy seguro de cómo iba a sobreescribir esto lo suficientemente temprano en la secuencia de inicio de Rails.

Tal vez una tercera opción es eliminar : active_record de config.frameworks, y luego crear 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.

Espero que haya algo simple y obvio que no he encontrado, como una característica de ActiveRecord que me permite optar por abandonar database.yml y proporcionar configuraciones alternativas mediante programación.

Answer 1

Esta es una pregunta antigua, pero en Rails 4 puede simplemente usar una variable de entorno y tener una base de datos en blanco o faltante .yml ( DATABASE_URL anulará cualquier base de datos.yml)

DATABASE_URL=postgres://myuser:[email protected]:5432/my-database-name

más aquí: http://edgeguides.rubyonrails.org/configuring.html#connection-preference

Answer 2

Esto parece funcionar en Rails 3.2.2

module MyApp
class Application < Rails::Application
self.paths[''config/database''] = ''config/another_db.yml''
end
end

Answer 3

Hay dos trucos que podrían ayudar aquí. Una es lo que has tocado, que consiste en aplicar parches a la rutina que se carga en la configuración de la base de datos, y eso es algo que vale la pena explorar. Lo bueno de Ruby es que puedes arreglar todo lo que no te gusta y reemplazarlo con algo mejor. La responsabilidad aquí es que una versión más nueva de Rails podría usar un mecanismo diferente para la configuración y su parche hará que todo se rompa. Tal vez ese es un precio que vale la pena pagar.

El otro enfoque es mantener el archivo database.yml en el servidor en lugar de en su repositorio, y tener algún tipo de secuencia de comandos de implementación que lo vincule a la ubicación adecuada. La ventaja de este enfoque es que no tiene contraseñas importantes flotando en su sistema de control de versiones y puede actualizar la configuración de un servidor sin tener que parchear la aplicación.

Answer 4

Puede proporcionar sus propias personalizaciones de bases de datos directamente en su aplicación.rb: Parece que funciona bien con raíles 3.2. (Ten en cuenta, es una especie de parche de mono)

module MyApp
class Application < Rails::Application
# ... config
config.encoding = "utf-8"
def config.database_configuration
parsed = super
raise parsed.to_yaml # Replace this line to add custom connections to the hash from database.yml
end
end
end