-
Notifications
You must be signed in to change notification settings - Fork 24
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
Allow configuration to skip the execute_inline!
call
#137
base: master
Are you sure you want to change the base?
Conversation
5ddc99f
to
8accd92
Compare
…ation default to 'allowed', since that matches existing behavior
8accd92
to
39a6fa9
Compare
**Note:** When developing locally or running tests, LHM runs 'inline' by default, meaning that the | ||
extra table is not used and the original table is not replaced. If this behavior is not desirable | ||
for your project, you can disable it by setting `Lhm.disallow_inline!` in the appropriate | ||
environment file or initializer. |
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.
Let me know if you think more explanation (of why it does that, or why you might want to opt out of it) is warranted here.
Any chance of a review? I'd be happy to make other changes, but this repo feels somewhat forgotten :-/ |
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 has definitively tripped us a dozen times, but for a different reason
LHM does not support virtual columns / foreign keys, and if we forget to temporarily remove the foreign keys at the beginning of the migration, the migration will pass on Dev, but fail on Prod.
We would also like to be able to not run LHM inline on Dev because of theses difference of behavior, and catch errors early instead of catching them when they reach Prod...
Purpose
Since updating to lhm-shopify, we had a recurring issue where people would write a migration using LHM (we have it in our generator templates), but fill it with normal calls to migration methods like
add_column(:tablename, :colname, :string)
.Before the upgrade, these calls would get caught immediately, because the schema file wouldn't get the intended changes, and any staging stack based on that branch would not have the column present. But after the upgrade, these calls worked fine locally, and since our staging stacks are based on the schema file (not by running migrations from scratch), we only end up catching these problems in production.
When we realized what was happening, we tracked it to here - the explanations on the change make total sense, but in our case we'd much rather exclude
development
from inlining, so this problem will get caught locally. (You should probably consider dropping thedevelopment?
condition entirely - I expect other people are getting surprised here occasionally as well).Implementation
bundle exec rake specs
to run all specs)Lhm.disallow_inline!
andLhm.inline_allowed?
to the base module for configuration purposesLhm.inline_allowed?
to the Railtie. Didn't see any tests on this thing, but I'm happy to go learn how to make one if you'd like.Verification
Confirmed locally that with the setting not supplied migrations run inline, and with
Lhm.disallow_inline!
called, they do not.Note
If you'd rather drop the 'auto-inline in development' part, that's a smaller change, and I'd be happy to update the PR :-)