-
Notifications
You must be signed in to change notification settings - Fork 479
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
create new standards tables #39065
create new standards tables #39065
Conversation
@@ -0,0 +1,12 @@ | |||
class CreateFrameworks < ActiveRecord::Migration[5.2] | |||
def change | |||
create_table :frameworks do |t| |
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.
For these migrations that create tables it might be worth it to explicitly set the character set to utf8 like this migration does to avoid some of the issues we've seen lately between staging and test.
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.
@bethanyaconnor I like the idea of making migrations utf8mb4-proof. when I added this and then tried to rollback my migrations, I got:
This migration uses execute, which is not automatically reversible.
To make the migration reversible you can either:
1. Define #up and #down methods in place of the #change method.
2. Use the #reversible method to define reversible behavior.
I didn't want to switch to defining #up and #down, but reversible
was pretty easy to add.
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.
Ah makes sense. Thanks for finding a solution!
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.
One suggestion. but otherwise looks great!
@@ -7,9 +7,14 @@ | |||
# organization_id :string(255) not null | |||
# description :text(65535) | |||
# concept :text(65535) | |||
# category_id :bigint | |||
# framework_id :integer |
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.
Why is category_Id a bigint and framework_id an integer?
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.
category_id is a bigint because that is what is generated by t.references
. framework_id
could be a bigint too and that's probably the best practice for any ids pointing to another table. However, since we only expect to have 10s of them and :integer
will be good for up to 2,000,000,000 frameworks, I don't think we'll run into any problems with framework_id being :integer
.
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.
One question but looks good. Exciting to see new models going in!
Finishes PLAT-749. For details, see Lesson Standards design doc.
Testing story
I tested this by running the migrations locally, since these are just adding new, empty tables and optional fields. I also ran the seed steps in #39095 to show that the standards data exported from CB can be fit into these fields.
Scalability
In terms of scalability, we expect only:
Reviewer Checklist: