Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 507 Vote(s) - 3.46 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Strategies for overriding database.yml?

#1
In my environment, the deployment servers have much of the connection information that is in the database.yml. That is, they know whether they are development, test or production servers, and they know their respective database connection information.

I can encapsulate this information in a Server class for example, so that I can retrieve the information:

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

and so on. I would like to deploy a Rails application and have it autoconfigure based on the Server settings. What is the best way to do this?

One way to do this is Erb in my database.yml:

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

I'm not too thrilled about doing it this way, but it would work. In this case, where would I put the 'server.rb' that defines the Server class--require it here in the yml? app/initializers gets loaded after ActiveRecord loads database.yml.

Another possible solution is to somehow override railties' database initializer:

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

The above is called only if :active_record is defined in config.frameworks. I'm not sure how I would go about overriding this early enough in the Rails startup sequence.

Maybe a third option is to *remove* :active_record from config.frameworks, and then create the connection later, say in the app initializers? I'm afraid this may have lots of unintended side effects.

I'm *hoping* that there's something simple and obvious that I haven't found, such as an ActiveRecord feature that allows me to opt out of database.yml and provide alternate config programmatically.


Reply

#2
This is an old question, but in Rails 4 you can simply use an environment variable and have a blank or missing database.yml (`DATABASE_URL` will override any database.yml)

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

more here:

[To see links please register here]

Reply

#3
This seems to work in Rails 3.2.2


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

#4
You can provide your own database customizations directly in your application.rb:
It seems to work nice rails 3.2. (Be warned though, it's a kind-of monkey patching)

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

Reply

#5
There's two tricks which might help here. One is what you've touched on, that being monkey-patching the routine that loads in the database configuration, and that's certainly something worth exploring. The nice thing about Ruby is you can pretty much patch out anything you don't like and replace it with something better. The liability here is that a newer version of Rails might use a different mechanism for configuration and your patch will cause everything to break. Maybe that's a price worth paying.

The other approach is to keep the `database.yml` file on the server instead of in your repository, and have some kind of deployment script that links it in to the appropriate location. The advantage to this approach is you don't have important passwords floating around in your version control system and you can update a server's configuration without having to patch the application.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through