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 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

r? @chancancode

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

def self.inherited(subclass) # :nodoc:
super
if subclass.superclass == Migration
subclass.send :include, Compatibility::Legacy
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mb use ? subclass.include Compatibility::Legacy

@matthewd matthewd force-pushed the migration-version branch 2 times, most recently from 3916985 to 060f1ce Compare September 9, 2015 01:29
@tenderlove
Copy link
Member

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 changed the title WIP: Add migration versioning via Migration subclasses Add migration versioning via Migration subclasses Dec 15, 2015
@matthewd matthewd closed this Dec 15, 2015
@matthewd matthewd reopened this Dec 15, 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 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
@jeremy
Copy link
Member

jeremy commented Dec 15, 2015

🤘

@matthewd matthewd deleted the migration-version branch June 11, 2017 23:21
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
Development

Successfully merging this pull request may close these issues.

None yet

7 participants