Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NoMethodError: undefined method `perform' for nil:NilClass #88

Closed
ziaulrehman40 opened this issue Aug 28, 2019 · 9 comments
Closed

NoMethodError: undefined method `perform' for nil:NilClass #88

ziaulrehman40 opened this issue Aug 28, 2019 · 9 comments

Comments

@ziaulrehman40
Copy link

ziaulrehman40 commented Aug 28, 2019

Hi,

We are in process of upgrading a rails 4.2. app to latest rails version. We successfully upgraded to 5.0 and while upgrading to 5.1 we are blocked by this error, which seems to be coming from strong_migrations.

If i remove strong_migrations from the app, everything works.

Ruby: 2.6.3
Rails: 5.1.7

Caused by:
NoMethodError: undefined method `perform' for nil:NilClass
/.../.rvm/gems/ruby-2.6.3/gems/strong_migrations-0.4.1/lib/strong_migrations/migration.rb:14:in `method_missing'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:600:in `method_missing'
/....../db/migrate/20190802132723_add_xyz_table.rb:2:in `<class:AddXyzTable>'
/....../db/migrate/20190802132723_add_xyz.rb:1:in `<top (required)>'
/.../.rvm/gems/ruby-2.6.3/gems/activesupport-5.1.7/lib/active_support/dependencies.rb:292:in `require'
/.../.rvm/gems/ruby-2.6.3/gems/activesupport-5.1.7/lib/active_support/dependencies.rb:292:in `block in require'
/.../.rvm/gems/ruby-2.6.3/gems/activesupport-5.1.7/lib/active_support/dependencies.rb:258:in `load_dependency'
/.../.rvm/gems/ruby-2.6.3/gems/activesupport-5.1.7/lib/active_support/dependencies.rb:292:in `require'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:962:in `load_migration'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:958:in `migration'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:953:in `disable_ddl_transaction'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1305:in `use_transaction?'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1297:in `ddl_transaction'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1229:in `execute_migration_in_transaction'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1201:in `block in migrate_without_lock'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1200:in `each'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1200:in `migrate_without_lock'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1148:in `block in migrate'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1317:in `with_advisory_lock'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1148:in `migrate'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:1007:in `up'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/migration.rb:985:in `migrate'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/tasks/database_tasks.rb:171:in `migrate'
/.../.rvm/gems/ruby-2.6.3/gems/strong_migrations-0.4.1/lib/strong_migrations/database_tasks.rb:4:in `migrate'
/.../.rvm/gems/ruby-2.6.3/gems/activerecord-5.1.7/lib/active_record/railties/databases.rake:58:in `block (2 levels) in <top (required)>'
/.../.rvm/gems/ruby-2.6.3/gems/rake-12.3.3/exe/rake:27:in `<top (required)>'

Our migration is simple, something like:

class AddXyzTable < ActiveRecord::Migration[4.2]
  create_table :xyz do |t|
    t.integer "abc_id",             null: false
    t.integer "efg_id", null: false
  end

  add_index "xyz", ["abc_id", "efg_id"], name: "index_xyz_on_abc_id_and_efg_id", using: :btree
  add_index "xyz", ["efg_id", "abc_id"], name: "index_xyz_on_efg_id_and_abc_id", using: :btree
end

Till now, it seems to be nothing related to our code, if it turns out to be, I will report here.

Thanks!

@ankane
Copy link
Owner

ankane commented Aug 28, 2019

Hey @ziaulrehman40, Strong Migrations is tested against Rails 5.1 (https://travis-ci.org/ankane/strong_migrations), so think something else in your app may be interfering with it.

@ankane
Copy link
Owner

ankane commented Aug 28, 2019

@checker should be set on initialization, but maybe another gem is overriding it?

@checker = StrongMigrations::Checker.new(self)

@ziaulrehman40
Copy link
Author

It was working fine on 4.2 and 5.0, i can check what else ot updated while migrating on 5.1.

Though nothing really stands out, but I updated haml-rails, pg and added listen gem.

Nothing else i can in my changelog. I can try reverting these gem updates/additions if that helps.

@ziaulrehman40
Copy link
Author

No, didn't help. I undid all gemfile changes and still same.

@ankane
Copy link
Owner

ankane commented Aug 28, 2019

The error doesn't occur in the test suite or a fresh Rails 5.1 app, so all signs point to something in your app.

@ziaulrehman40
Copy link
Author

Yeah i understand that, but we must hunt it down whatever it is.
I will try to spend some time on this and as soon as I find something i will report.

Just to add,

  1. StrongMigrations.start_after is set, and there are a few migrations that run just fine after this set timestamp value, and this specific one fails which is near end of the list(second last).

  2. If i comment this specific migration's actual migration stuff, it passes over it just fine.

@ziaulrehman40
Copy link
Author

Oh found it...

If you look closely, you can see there is no def change or def up in the migration i have pasted above, that was the issue. wrapping migration in a def change fixed it.

I am not sure how it was even working in older versions... this is confusing.

ankane added a commit that referenced this issue Aug 28, 2019
@ankane
Copy link
Owner

ankane commented Aug 28, 2019

Migrations inherit from ActiveRecord::Schema, which can run operations without methods. Anyways, I updated the code to be more robust to this scenario.

@ziaulrehman40
Copy link
Author

Thankyou @ankane , this approach was what came to my mind when i was investigating, but you were super fast to push a commit. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants