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

Add migration versioning via Migration subclasses #21538

Merged
merged 8 commits into from Dec 15, 2015

Conversation

@matthewd
Copy link
Member

matthewd commented Sep 8, 2015

This PR implements the migration versioning infrastructure, and restores the previous default on timestamps null: (when in 4.2-compatibility mode).

@rails-bot
Copy link

rails-bot commented Sep 8, 2015

r? @chancancode

(@rails-bot has picked a reviewer for you, use r? to override)

@matthewd matthewd force-pushed the matthewd:migration-version branch from 713a87c to 483ef3a Sep 8, 2015
@matthewd matthewd assigned matthewd and unassigned chancancode Sep 8, 2015
def self.inherited(subclass) # :nodoc:
super
if subclass.superclass == Migration
subclass.send :include, Compatibility::Legacy

This comment has been minimized.

@artofhuman

artofhuman Sep 8, 2015 Contributor

mb use ? subclass.include Compatibility::Legacy

@matthewd matthewd force-pushed the matthewd:migration-version branch 2 times, most recently Sep 9, 2015
@tenderlove
Copy link
Member

tenderlove commented Sep 9, 2015

LGTM. I guess the main things to point out is the difference between upgrade strategies, namely this vs this. I think the strategy in this PR is easier. But, FWIW, both PRs generate a superclass, so we can switch to the strategy pattern in #21037 at pretty much any point if we need to.

The other thing is that this PR doesn't support deriving the version from the file name. IMO the syntax proposed here is pretty unoffensive, so I'm not sure if we still want / need to derive this from the file name.

I think the main hurdle here is that we need to figure out if the filename stuff is still required.

/cc @dhh @jeremy

@dhh
Copy link
Member

dhh commented Sep 9, 2015

I'm happy enough with the superclass having the version identifier. Don't need the filename to include it too, imo. This is actually a pretty elegant solution.

@matthewd matthewd force-pushed the matthewd:migration-version branch Dec 15, 2015
@matthewd matthewd changed the title WIP: Add migration versioning via Migration subclasses Add migration versioning via Migration subclasses Dec 15, 2015
@matthewd matthewd force-pushed the matthewd:migration-version branch Dec 15, 2015
@matthewd matthewd closed this Dec 15, 2015
@matthewd matthewd reopened this Dec 15, 2015
@matthewd matthewd force-pushed the matthewd:migration-version branch Dec 15, 2015
matthewd added 8 commits Dec 5, 2015
If we use a real version, at best that'll be an onerous update required
for each release; at worst, it will encourage users to write new
migrations against an older version than they're using.

The other option would be to leave these bare, without any version
specifier. But as that's just a variant spelling of "4.2", it would seem
to raise the same concerns as above.
Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.

Application code should *not* do this.
.. it also showed a deprecation warning, but we obviously needn't retain
that.
Even though this means more things to change when we bump after a
release, it's more important that our examples are directly copyable.
@matthewd matthewd force-pushed the matthewd:migration-version branch to 97c7716 Dec 15, 2015
matthewd added a commit that referenced this pull request Dec 15, 2015
Add migration versioning via Migration subclasses
@matthewd matthewd merged commit cd90f4f into rails:master Dec 15, 2015
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@jeremy
Copy link
Member

jeremy commented Dec 15, 2015

🤘

@kenchan0130 kenchan0130 mentioned this pull request May 14, 2017
1 of 1 task complete
@matthewd matthewd deleted the matthewd:migration-version branch Jun 11, 2017
prathamesh-sonpatki added a commit to prathamesh-sonpatki/archer that referenced this pull request Feb 3, 2020
We can use the `Migration.current_version` provided by Rails for the
migration version.
This method was introduced in rails/rails#21538
hamuyuuki added a commit to hamuyuuki/mysql_online_migrations that referenced this pull request May 7, 2020
robbkidd added a commit to chef/supermarket that referenced this pull request Jun 29, 2020
Rails 5.0 introduced a Migration API.[1] ActiveRecord::Migration classes
are Rails version specific.

Rails 5.0 was pretty forgiving about migration classes that didn't have
a version annotation. Rails 5.1 is not. These changes are in preparation for
new migrations to be added and so only touch existing files.

Incidentally, it is `rake db:migrate` that reeeeally wants these old
migration classes to declare for which Rails version they were written.
`rails db:migrate` seemed to accept them just fine. But we rake
everywhere, so let's add the annotations to keep up with the framework.

[1] rails/rails#21538

Signed-off-by: Robb Kidd <rkidd@chef.io>
robbkidd added a commit to chef/supermarket that referenced this pull request Jun 30, 2020
Rails 5.0 introduced a Migration API.[1] ActiveRecord::Migration classes
are Rails version specific.

Rails 5.0 was pretty forgiving about migration classes that didn't have
a version annotation. Rails 5.1 is not. These changes are in preparation for
new migrations to be added and so only touch existing files.

Incidentally, it is `rake db:migrate` that reeeeally wants these old
migration classes to declare for which Rails version they were written.
`rails db:migrate` seemed to accept them just fine. But we rake
everywhere, so let's add the annotations to keep up with the framework.

[1] rails/rails#21538

Signed-off-by: Robb Kidd <rkidd@chef.io>
robbkidd added a commit to chef/supermarket that referenced this pull request Jun 30, 2020
Rails 5.0 introduced a Migration API.[1] ActiveRecord::Migration classes
are Rails version specific.

Rails 5.0 was pretty forgiving about migration classes that didn't have
a version annotation. Rails 5.1 is not. These changes are in preparation for
new migrations to be added and so only touch existing files.

Incidentally, it is `rake db:migrate` that reeeeally wants these old
migration classes to declare for which Rails version they were written.
`rails db:migrate` seemed to accept them just fine. But we rake
everywhere, so let's add the annotations to keep up with the framework.

[1] rails/rails#21538

Signed-off-by: Robb Kidd <rkidd@chef.io>
robbkidd added a commit to chef/supermarket that referenced this pull request Jun 30, 2020
Rails 5.0 introduced a Migration API.[1] ActiveRecord::Migration classes
are Rails version specific.

Rails 5.0 was pretty forgiving about migration classes that didn't have
a version annotation. Rails 5.1 is not. These changes are in preparation for
new migrations to be added and so only touch existing files.

Incidentally, it is `rake db:migrate` that reeeeally wants these old
migration classes to declare for which Rails version they were written.
`rails db:migrate` seemed to accept them just fine. But we rake
everywhere, so let's add the annotations to keep up with the framework.

[1] rails/rails#21538

Signed-off-by: Robb Kidd <rkidd@chef.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants
You can’t perform that action at this time.