-
Notifications
You must be signed in to change notification settings - Fork 900
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
Don't load container models from app folder in migration #7312
Don't load container models from app folder in migration #7312
Conversation
@lpichler Is there a spec for this in spec/migrations? |
@Fryguy there is no spec for it, so I will add it to this PR, thanks |
/me is upset that got merged in the first place without a spec :( |
self.inheritance_column = :_type_disabled # disable STI | ||
end | ||
|
||
class ContainerProject < ActiveRecord::Base; end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was pre-rails 5, but in new migrations created with rails 5, I believe these should be < ApplicationRecord; end
... Right @matthewd?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No.
Part of the advantage of ApplicationRecord is that we can leave AR::Base unmolested, which is exactly what migrations want: a plain ordinary AR object with no app-code-of-the-day surprises.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matthewd That is really interesting and good to know! I didn't even think of that.
d9fbca2
to
ed2e4d8
Compare
|
||
def stub_for(table) | ||
send(stub_name_for(table)) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably shouldn't define these methods globally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After you remove the tests for schema changes (columns dropped/added, see below), do we need these methods anymore? Maybe just do the work in-line if it's only a few places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it is only on few places now 👍
and creation_timestamp was renamed with correct value
ed2e4d8
to
ff856e2
Compare
Checked commits lpichler/manageiq@4087231~...ff856e2 with ruby 2.2.3, rubocop 0.37.2, and haml-lint 0.16.1 |
@jrafanie I removed testing of schema, now it looks simplier, thanks for your feedback! |
for possibility to use good_migration gem
related #6739
change from
CONTAINER_TABLES to
CONTAINER_MODELSwas needed because this command
t.to_s.classify.constantize.update_all` is loading it from app/ folder even if we are defining these models in the migrationthis changes have been made by this script
cc @jrafanie @Fryguy