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
Dump the database schema containing the current Rails version #44286
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
rafaelfranca
force-pushed
the
rm-multi-version-schema
branch
from
January 28, 2022 22:14
79f1c48
to
72d4de4
Compare
rafaelfranca
force-pushed
the
rm-multi-version-schema
branch
from
January 28, 2022 22:44
72d4de4
to
b7f15a2
Compare
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.
Thanks, @rafaelfranca for addressing this 🙇
davidstosik
reviewed
Feb 1, 2022
Comment on lines
391
to
416
### Rails version is now included in the Active Record schema dump | ||
|
||
Rails 7.0 changed some default values for some column types. To avoid that application upgrading from 6.1 to 7.0 | ||
load the current schema using the new 7.0 defaults, Rails now includes the version of the framework in the schema dump. | ||
|
||
This means that after the upgrade, as soon the schema is loaded, you will see many changes to that file, including | ||
some column information. Make sure to review the new schema file content and commit it to your repository. | ||
|
||
The schema file will look like this: | ||
|
||
```ruby | ||
# This file is auto-generated from the current state of the database. Instead | ||
# of editing this file, please use the migrations feature of Active Record to | ||
# incrementally modify your database, and then regenerate this schema definition. | ||
# | ||
# This file is the source Rails uses to define your schema when running `bin/rails | ||
# db:schema:load`. When creating a new database, `bin/rails db:schema:load` tends to | ||
# be faster and is potentially less error prone than running all of your | ||
# migrations from scratch. Old migrations may fail to apply correctly if those | ||
# migrations use external dependencies or application code. | ||
# | ||
# It's strongly recommended that you check this file into your version control system. | ||
|
||
ActiveRecord::Schema[7.0].define(version: 2022_01_28_123512) do | ||
``` | ||
|
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.
Thank you! 🎉
rafaelfranca
force-pushed
the
rm-multi-version-schema
branch
3 times, most recently
from
February 7, 2022 18:57
254b0e8
to
aff7994
Compare
Since #42297, Rails now generates datetime columns on MySQL with a default precision of 6. This means that users upgrading to Rails 7.0 from 6.1, when loading the database schema, would get the new precision value, which would not match the production schema. To avoid problems like this in the future, Rails will now freeze `ActiveRecord::Schema` class to be the 7.0 implementation, and will allow access to other version using the same mechanism of `ActiveRecord::Migration`. The schema dumper will generate the new format which will include the Rails version and will look like this: ``` ActiveRecord::Schema[7.0].define ``` Related to #43934 and #43909.
rafaelfranca
force-pushed
the
rm-multi-version-schema
branch
from
February 7, 2022 18:58
aff7994
to
2d76373
Compare
rafaelfranca
added a commit
that referenced
this pull request
Feb 7, 2022
Dump the database schema containing the current Rails version
eddierubeiz
added a commit
to sciencehistory/scihist_digicoll
that referenced
this pull request
Jan 5, 2023
remove obsolete admin? method note: this is our first rails migration since we moved to rails 7, so schema.rb specifies the rails version and changes the precision default for datetime columns. see: https://rubyonrails.org/2022/2/11/this-week-in-rails-rails-7-0-2-schema-versioning-based-on-the-rails-version-and-more-cbcb0592 rails/rails#44286
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.
Since #42297, Rails now generate datetime columns on MySQL with a default precision of 6. This means that users upgrading to Rails 7.0 from 6.1, when loading the database schema, would get the new precision value, which would not match the production schema.
To avoid this, Rails will now freeze
ActiveRecord::Schema
class to be the 6.1 implementation, and will allow access to other version using the same mechanism ofActiveRecord::Migration
.The schema dumper will generate the new format which will include the Rails version and will look like this:
Related to #43934 and #43909.