Add migration versioning via Migration subclasses #21538
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @chancancode (@rails-bot has picked a reviewer for you, use r? to override) |
matthewd
force-pushed
the
migration-version
branch
from
713a87c to
483ef3a
Compare
| def self.inherited(subclass) # :nodoc: | ||
| super | ||
| if subclass.superclass == Migration | ||
| subclass.send :include, Compatibility::Legacy |
There was a problem hiding this comment.
mb use ? subclass.include Compatibility::Legacy
matthewd
force-pushed
the
migration-version
branch
2 times, most recently
from
3916985 to
060f1ce
Compare
|
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. |
|
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
force-pushed
the
migration-version
branch
from
060f1ce to
ddea354
Compare
matthewd
changed the title
matthewd
force-pushed
the
migration-version
branch
from
ddea354 to
77f5580
Compare
matthewd
force-pushed
the
migration-version
branch
from
77f5580 to
ab78694
Compare
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
force-pushed
the
migration-version
branch
from
ab78694 to
97c7716
Compare
matthewd
added a commit
that referenced
this pull request
Dec 15, 2015
Add migration versioning via Migration subclasses
|
🤘 |
This was referenced Feb 1, 2016
1 task
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements the migration versioning infrastructure, and restores the previous default on
timestamps null:(when in 4.2-compatibility mode).