0

I have a private Rails app that I'm trying to install locally. It's currently running in a hosting environment but I'd like to install it locally to begin making changes. I've already worked out that I can make deploy updates to the 'live' server but a recent misstep 'reinforced the need to make changes locally'.

After a fair amount of reading I determined that I needed to...

  1. Grab the latest repository (It uses SVN)
  2. Grab the database mysqldump -u root --databases my_db_development > my_db_development_0110.sql
  3. Imported database locally (MAMP/Sequel Pro noticed there was no data in the database although there is data in the live server - is that strange?)
  4. Validate database.yml (adapter: mysql, encoding: utf8, database: my_db_development, username: root, password: , host: localhost)

The next step I assumed was to get into my local directory and rake db:migrate --trace which returned the output below.

I'm a bit unsure how to go about understanding and identifying why I'm unable to move forward. Any ideas as to whether I've missed something or perhaps need to change something?

(in /Users/me/my_repo)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
rake aborted!
Multiple migrations have the version number 1
/Users/me/.gem/ruby/1.8/gems/activerecord-2.1.2/lib/active_record/migration.rb:472:in `migrations'
/Users/me/.gem/ruby/1.8/gems/activerecord-2.1.2/lib/active_record/connection_adapters/mysql_adapter.rb:15:in `inject'
/Users/me/.gem/ruby/1.8/gems/activerecord-2.1.2/lib/active_record/migration.rb:465:in `each'
/Users/me/.gem/ruby/1.8/gems/activerecord-2.1.2/lib/active_record/migration.rb:465:in `inject'
/Users/me/.gem/ruby/1.8/gems/activerecord-2.1.2/lib/active_record/migration.rb:465:in `migrations'
/Users/me/.gem/ruby/1.8/gems/activerecord-2.1.2/lib/active_record/migration.rb:431:in `migrate'
/Users/me/.gem/ruby/1.8/gems/activerecord-2.1.2/lib/active_record/migration.rb:373:in `up'
/Users/me/.gem/ruby/1.8/gems/activerecord-2.1.2/lib/active_record/migration.rb:356:in `migrate'
/Users/me/.gem/ruby/1.8/gems/rails-2.1.2/lib/tasks/databases.rake:99
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:597:in `invoke_with_call_chain'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `each'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/bin/rake:31
/usr/bin/rake:19:in `load'
/usr/bin/rake:19
Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Shawn
  • 633
  • 1
  • 6
  • 13

2 Answers2

1

It seems you have duplicate migrations in your migrate directory. Check the prefixes of the migrations under database_migrations/migrate and make sure you haven't copied multiple versions or created migrations out of sync with the repository.

Dave Sims
  • 5,060
  • 3
  • 24
  • 26
  • db/migrate shows 10 migrations two of which have a prefix of 001 (001_completed and 001_create_tokens) is that considered a duplicate? – Shawn Jan 28 '10 at 05:32
  • it's the number that matters, not the name suffixed to the file name, so rails thinks there is a duplicate. It has to be sequential because otherwise the migrate script can't work out which migration to run first. – Ken Liu Jan 28 '10 at 05:38
  • Ok, that makes sense. So is it as simple as renaming one of the files? – Shawn Jan 28 '10 at 06:24
  • Yes, more than likely. And if you upgrade to 2.1 or later, Rails will use time stamps instead of sequential numbers, making collisions like this *almost* impossible. – Dave Sims Jan 28 '10 at 14:22
  • Dave/Ken - thanks for your input help. I did some research on Migrations last night and have a better understanding of the generator and how the prefix is created. While I haven't made any changes to the db/migrate files (yet), this morning I was unable to start MySQL locally. After removing the database I created via Sequel Pro and uninstalling MAMP, I imported the same db and reinstalled MAMP. I then went to my app's directory and entered "ruby script/server". I'm don't understand why but 'suddenly' the app is visible at localhost:3000. Thanks for your help...learned a bunch of things! – Shawn Jan 28 '10 at 21:57
1

If you are importing the entire database from your production environment, then you won't need to run db:migrate - the database/schema should already be up to date. It sounds like you are missing data in your local database and something went wrong with the import.

Ken Liu
  • 22,503
  • 19
  • 75
  • 98