winton / also_migrate Goto Github PK

When trying to upgrade an application to Rails 3.1, the naming scheme of the migration files breaks. Specifically, the timestamp does not appear in the name. Instead of the expected

db/migrate/20111018130243_add_foo_to_user.rb

I get

db/migrate/_add_foo_to_user.rb

If I comment out the block of configuration code for the also_migrate gem, the migration files are properly generated. Uncommenting the same lines recreates the issue.

The code seemed to work properly under Rails 3.0.7, but the issue appears under 3.1.1.

The block of code is:

require 'also_migrate'
AlsoMigrate.configuration = [
  {:source => 'questions', :destination => 'question_archives', :add => [['moved_at', :datetime]], :indexes => :id},
  {:source => 'answers', :destination => 'answer_archives', :add => [['moved_at', :datetime]], :indexes => :id},
  {:source => 'descriptions', :destination => 'description_archives', :add => [['moved_at', :datetime]], :indexes => :id}
]

The corresponding entry in the Gemfile is:

gem 'also_migrate'

Gemfile.lock indicates that the version of also_migrate being pulled in is 0.3.5.

Not sure if there is more information I should be providing. Thanks.

When installing via Bundler, getting errors:

/Users/blake/.rvm/rubies/ruby-1.9.2-p290-railsexpress/lib/ruby/1.9.1/psych.rb:148:in `parse': couldn't parse YAML at line 3 column 9 (Psych::SyntaxError)
    from /Users/blake/.rvm/rubies/ruby-1.9.2-p290-railsexpress/lib/ruby/1.9.1/psych.rb:148:in `parse_stream'
    from /Users/blake/.rvm/rubies/ruby-1.9.2-p290-railsexpress/lib/ruby/1.9.1/psych.rb:119:in `parse'
    from /Users/blake/.rvm/rubies/ruby-1.9.2-p290-railsexpress/lib/ruby/1.9.1/psych.rb:106:in `load'

also_migrate ignores migrations that use the new "change" method rather than self.up and self.down

For postgres 8.4 sql like this "CREATE TABLE archived_articles LIKE articles" is invalid.
This is correct one "CREATE TABLE archived_articles (LIKE articles)"

Hi Winton,
I tried to use the indexes options to set a primary key, on a cloned table.
But nothing append, I falled back and remove the option, and the index was correctly created as the original table. Not really an issue for me, but probably for other.

bye

The current extensions to the migration class do not support reversible migrations via the change method.