Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

rake db:drop, db:create don't work

#4569

rake db:drop:all says "This task only modifies local databases. letexa is on a remote host."

rake db:drop doesn't say anything but does not do anything, same with db:create.

In config/database.yml I have "host: mysql" (for all three db's), but
a) the name points to localhost, so there should be no "remote host" complaint (I use a name other than localhost to be able to have that name point somewhere else on another system running the app)
b) db:drop should have the same message as drop:all if that's the problem why it does not do anything

Reported by Michael Hasenstein · May 10th, 2010 @ 02:53 PM

State: stale
Milestone: none
Assigned to: nobody
Importance: Low

Activity

  1. Anil Wadghule
    Anil Wadghule

    Do you mean your 'mysql' host name is pointing to 'localhost' i.e. 127.0.0.1 ?

    May 11th, 2010 @ 07:27 PM

  2. Michael Hasenstein
  3. Ryan Bigg
    Ryan Bigg
    • Tag set to bugmash
    • State changed from new to incomplete

    Please add further steps to reproduce this problem.

    May 13th, 2010 @ 11:47 PM

  4. Seivan
    Seivan

    Alright I tried to redo this

    127.0.0.1 mysql
    dscacheutil -flushcache

    rake db:create
    rake db:migrate
    rake db:populate

    all good so far.

    Post.all => [Post....]

    rake db:drop:all

    This task only modifies local databases. blogstain_development is on a remote host.
    This task only modifies local databases. blogstain_test is on a remote host.
    This task only modifies local databases. blogstain_test is on a remote host.
    Couldn't drop blogstain : #<Mysql::Error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)>

    However
    rake db:drop works as intended.

    So, if you wanna deal with the other environments, just set it before dropping;
    RAILS_ENV="test" rake db:drop

    May 15th, 2010 @ 12:51 AM

  5. Seivan
    Seivan

    Argh, can't edit post.
    Thanks to NathanielJ from #railsbridge

    This piece of code gets called when doing a rake db:drop:all
    So.. basically it can't tell what addresses you got inside /etc/hosts :-)

    def local_database?(config, &block)

    if %w( 127.0.0.1 localhost ).include?(config['host']) || config['host'].blank?
      yield
    else
      $stderr.puts "This task only modifies local databases. #{config['database']} is on a remote host."
    end
    

    end

    May 15th, 2010 @ 12:56 AM

  6. Rohit Arondekar
    Rohit Arondekar

    This raises the question as to why the check => if %w( 127.0.0.1 localhost ).include?(config['host']) exists? Can somebody clear up as to why the remote db can't be dropped? One thing that comes to my mind is that most of the times the user of the remote db may not have permission to drop the entire db?

    May 15th, 2010 @ 05:43 AM

  7. David Trasbo
    David Trasbo
    • Importance changed from to Low

    Rohit,

    I think it might be to stop people from accidentally deleting production databases. It's not something I know, though.

    June 29th, 2010 @ 10:49 AM

  8. Lenary
    Lenary

    It is indeed to prevent people destroying data on separate hosts. if it points at localhost, why can't you just have it as localhost?

    July 30th, 2010 @ 10:51 PM

  9. Santiago Pastorino
    Santiago Pastorino
    • State changed from incomplete to open

    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.

    February 2nd, 2011 @ 04:34 PM

  10. Santiago Pastorino
    Santiago Pastorino
    • State changed from open to stale

    February 2nd, 2011 @ 04:34 PM

  11. bingbing