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

Add config to disable schema dump after migration #13948

Merged
merged 1 commit into from Feb 6, 2014

Conversation

Projects
None yet
6 participants
@emilsoman
Contributor

emilsoman commented Feb 5, 2014

  • Add a config on active_record named dump_schema_after_migration
  • Schema dump doesn't happen if the config is set to false
  • Set default value of the config to true
  • Set config in generated production and test environment files to false
  • Update configuration guide
  • Update CHANGELOG

@senny senny added the activerecord label Feb 5, 2014

@senny

This comment has been minimized.

Show comment
Hide comment
@senny
Member

senny commented Feb 5, 2014

Show outdated Hide outdated activerecord/CHANGELOG.md
Show outdated Hide outdated activerecord/CHANGELOG.md
@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Feb 5, 2014

Member

@emilsoman this is looking good. I added a few minor comments about formatting and style.

/cc @fxn

Member

senny commented Feb 5, 2014

@emilsoman this is looking good. I added a few minor comments about formatting and style.

/cc @fxn

@senny senny closed this Feb 5, 2014

@senny senny reopened this Feb 5, 2014

@emilsoman

This comment has been minimized.

Show comment
Hide comment
@emilsoman

emilsoman Feb 5, 2014

Contributor

@senny , @carlosantoniodasilva Thanks for the feedback ! Fixed formatting and style issues. Anything else ?

Contributor

emilsoman commented Feb 5, 2014

@senny , @carlosantoniodasilva Thanks for the feedback ! Fixed formatting and style issues. Anything else ?

@fxn

This comment has been minimized.

Show comment
Hide comment
@fxn

fxn Feb 5, 2014

Member

Hey, gonna have a look today.

Member

fxn commented Feb 5, 2014

Hey, gonna have a look today.

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Feb 5, 2014

Member

@emilsoman you will need to squash all your commits into a single one but let's wait for feedback from @fxn first.

Member

senny commented Feb 5, 2014

@emilsoman you will need to squash all your commits into a single one but let's wait for feedback from @fxn first.

@fxn

This comment has been minimized.

Show comment
Hide comment
@fxn

fxn Feb 5, 2014

Member

Looks good. Just a couple of details.

I believe the flag should not appear in test.rb. I explained the rationale in the mailing list but the summary is that since you are not supposed to run migrations in the test environment, it looks strange that the config file says anything about them. The comment is enlightening, see "Do not dump schema after migrations", "in the test environment? which migrations? I am not supposed to run migrations in the test environment!", the user may wonder.

Since migrations do not run, the implicit true value is fine, it won't hurt.

Then some details regarding the values of the flag. We try to avoid using singletons in docs and tests. As far as the user is concerned this is a flag. We could assign anything to it that is true, and the user can set it to nil if he so wishes, we only use the flag for its boolean interpretation. I am going to do some inline comments to be more specific.

Member

fxn commented Feb 5, 2014

Looks good. Just a couple of details.

I believe the flag should not appear in test.rb. I explained the rationale in the mailing list but the summary is that since you are not supposed to run migrations in the test environment, it looks strange that the config file says anything about them. The comment is enlightening, see "Do not dump schema after migrations", "in the test environment? which migrations? I am not supposed to run migrations in the test environment!", the user may wonder.

Since migrations do not run, the implicit true value is fine, it won't hurt.

Then some details regarding the values of the flag. We try to avoid using singletons in docs and tests. As far as the user is concerned this is a flag. We could assign anything to it that is true, and the user can set it to nil if he so wishes, we only use the flag for its boolean interpretation. I am going to do some inline comments to be more specific.

Show outdated Hide outdated activerecord/CHANGELOG.md
Show outdated Hide outdated activerecord/CHANGELOG.md
Show outdated Hide outdated activerecord/CHANGELOG.md
@emilsoman

This comment has been minimized.

Show comment
Hide comment
@emilsoman

emilsoman Feb 6, 2014

Contributor

@fxn , Thanks for the amazing feedback ! I've removed the config from config/environments/test.rb because what you said makes perfect sense. I've fixed the grammatical issues that you pointed out. I am not sure about a couple of things for which I've left inline comments. Please take a look whenever you can. Thank you :)

Contributor

emilsoman commented Feb 6, 2014

@fxn , Thanks for the amazing feedback ! I've removed the config from config/environments/test.rb because what you said makes perfect sense. I've fixed the grammatical issues that you pointed out. I am not sure about a couple of things for which I've left inline comments. Please take a look whenever you can. Thank you :)

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Feb 6, 2014

Member

@emilsoman sorry for pointing you in the wrong direction with true and false 😓

Member

senny commented Feb 6, 2014

@emilsoman sorry for pointing you in the wrong direction with true and false 😓

@fxn

This comment has been minimized.

Show comment
Hide comment
@fxn

fxn Feb 6, 2014

Member

Exactly :), the idea is that we want to communicate that the default config is such that the schema is not dumped in production. The exact value needed to enable or disable the flag doesn't matter, any value works (interpreted as a flag).

Member

fxn commented Feb 6, 2014

Exactly :), the idea is that we want to communicate that the default config is such that the schema is not dumped in production. The exact value needed to enable or disable the flag doesn't matter, any value works (interpreted as a flag).

@fxn

View changes

Show outdated Hide outdated activerecord/CHANGELOG.md
@fxn

View changes

Show outdated Hide outdated activerecord/lib/active_record/core.rb
@fxn

View changes

Show outdated Hide outdated activerecord/lib/active_record/core.rb
@fxn

View changes

Show outdated Hide outdated guides/source/configuring.md
@fxn

View changes

Show outdated Hide outdated railties/CHANGELOG.md
@fxn

View changes

Show outdated Hide outdated railties/CHANGELOG.md
@fxn

This comment has been minimized.

Show comment
Hide comment
@fxn

fxn Feb 6, 2014

Member

I made some editorial comments. Almost there!

Member

fxn commented Feb 6, 2014

I made some editorial comments. Almost there!

@emilsoman

This comment has been minimized.

Show comment
Hide comment
@emilsoman

emilsoman Feb 6, 2014

Contributor

@fxn Fixed. Can I squash the commits ?

Contributor

emilsoman commented Feb 6, 2014

@fxn Fixed. Can I squash the commits ?

@fxn

View changes

Show outdated Hide outdated railties/test/application/configuration_test.rb
@fxn

View changes

Show outdated Hide outdated railties/test/application/configuration_test.rb
@fxn

View changes

Show outdated Hide outdated railties/test/application/rake/migrations_test.rb
@fxn

View changes

Show outdated Hide outdated railties/test/application/rake/migrations_test.rb
@fxn

This comment has been minimized.

Show comment
Hide comment
@fxn

fxn Feb 6, 2014

Member

Awesome @emilsoman, added a few minor remarks and I think it is good to go. If you revise those and squash we'll apply.

Member

fxn commented Feb 6, 2014

Awesome @emilsoman, added a few minor remarks and I think it is good to go. If you revise those and squash we'll apply.

Add config to disable schema dump after migration
* Add a config on Active Record named `dump_schema_after_migration`
* Schema dump doesn't happen if the config is set to false
* Set default value of the config to true
* Set config in generated production environment file to false
* Update configuration guide
* Update CHANGELOG
@emilsoman

This comment has been minimized.

Show comment
Hide comment
@emilsoman

emilsoman Feb 6, 2014

Contributor

@fxn , done :)

Contributor

emilsoman commented Feb 6, 2014

@fxn , done :)

@fxn

This comment has been minimized.

Show comment
Hide comment
@fxn

fxn Feb 6, 2014

Member

Fantastic! Thanks a lot for working on this 😄 ❤️

Member

fxn commented Feb 6, 2014

Fantastic! Thanks a lot for working on this 😄 ❤️

@emilsoman

This comment has been minimized.

Show comment
Hide comment
@emilsoman

emilsoman Feb 6, 2014

Contributor

Thanks for guiding this into good shape. You guys were super helpful. Thank you !

Contributor

emilsoman commented Feb 6, 2014

Thanks for guiding this into good shape. You guys were super helpful. Thank you !

@fxn fxn merged commit 8806768 into rails:master Feb 6, 2014

@fxn

This comment has been minimized.

Show comment
Hide comment
@fxn

fxn Feb 6, 2014

Member

Merged here.

Member

fxn commented Feb 6, 2014

Merged here.

@bronson

This comment has been minimized.

Show comment
Hide comment
@bronson

bronson Jan 19, 2016

Contributor

If anyone else is wondering why this config was added: https://groups.google.com/forum/#!topic/rubyonrails-core/h4cQXmKuB7M

Dumping the production schema seems harmless enough to me. Then again, I've never had a database with enough tables where time is an issue.

Contributor

bronson commented on 8806768 Jan 19, 2016

If anyone else is wondering why this config was added: https://groups.google.com/forum/#!topic/rubyonrails-core/h4cQXmKuB7M

Dumping the production schema seems harmless enough to me. Then again, I've never had a database with enough tables where time is an issue.

@gkop

This comment has been minimized.

Show comment
Hide comment
@gkop

gkop Apr 6, 2018

Contributor

Scott I agree it's generally harmless. It bit us though when we switched from schema to structure, as we rightfully didn't supply pg_dump in our production environments. So grateful for Emil's contribution :)

Contributor

gkop commented Apr 6, 2018

Scott I agree it's generally harmless. It bit us though when we switched from schema to structure, as we rightfully didn't supply pg_dump in our production environments. So grateful for Emil's contribution :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment