This project is archived and is in readonly mode.

#4141 open
Kandada Boggu

The rake tasks db:create and db:drop throws an error when the database.yml file is configured in a non default location.

Reported by Kandada Boggu | March 10th, 2010 @ 09:11 AM | in 2.3.10

The rake tasks db:create and db:drop throws an error when the database.yml file is configured in a non default location.

The database.yml file location is configured using the database_configuration_file attribute of Rails::Configuration class.

environment.rb

RAILS_GEM_VERSION = '2.3.5' unless defined? RAILS_GEM_VERSION
require File.join(File.dirname(__FILE__), 'boot')
Rails::Initializer.run do |config|
  config.time_zone = 'UTC'

  # configure the database.yml file location
  config.database_configuration_file = File.join("c:/siteconfig/test", 'database.yml')
end

Rake tasks db:drop and db:create throw the following error:

>rake db:drop
(in C:/test)
rake aborted!
No such file or directory - C:/test/config/database.yml
I am able to run the other rake tasks such as db:migrate. The rails application runs without any error.

I located the issue in db:load_config.

task :load_config => :rails_env do
 require 'active_record'
 ActiveRecord::Base.configurations = Rails::Configuration.new.database_configuration
end
This task ignores the database config file location override in environment.rb. Hence the location always defaults to RAILS_ROOT/config/database.yml.

Comments and changes to this ticket

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:54 PM

    • State changed from “new” to “open”
    • Tag changed from “databases.rake, rake_dev” to “databasesrake, rake_dev”

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:54 PM

    • State changed from “open” to “stale”
  • Kandada Boggu

    Kandada Boggu February 2nd, 2011 @ 07:21 PM

    • Assigned user set to “Santiago Pastorino”

    I can still reproduce this error on Rails 2.3.9. Please run rake db:create on the attached project to reproduce the error.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 08:33 PM

    • State changed from “stale” to “open”
    • Milestone set to “2.3.10”
    • Assigned user cleared.
    • Importance changed from “” to “Low”
  • Vijay Dev

    Vijay Dev February 12th, 2011 @ 07:44 PM

    • Tag changed from “databasesrake, rake_dev” to “configuration, database.yml, databasesrake, rake_dev”
    • Assigned user set to “Santiago Pastorino”

    The issue seems to be solved when I change the load_config task to depend on the environment task instead of rails_env and remove the assignment to ActiveRecord::Base.configurations. Is this a right approach? How can I test this?

    I would like to know the reasoning behind allowing the path to database.yml to be configurable.

    Also, there is at least one more issue concerning the database.yml path #1710

  • Kandada Boggu

    Kandada Boggu February 13th, 2011 @ 01:14 AM

    We have built a product using Rails framework. Most of our customers/field engineers have no ruby/rails background. When the product is installed, code resides in a directory with read permissions and log/config files reside in a directory with read/write permission. The config directory contain ONLY the files that an administrator can change, i.e. database.yml and app_config.yml. This done in order to avoid any mishaps in production systems.

    This is a common pattern for a corporate deployment. When we deploy on EC2, an EBS volume stores the configuration and log files and AMI has the project source.

  • Santiago Pastorino

    Santiago Pastorino February 13th, 2011 @ 04:50 AM

    • Assigned user cleared.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Attachments

Tags

Pages