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 UserLevelInfo Table #31429
Create UserLevelInfo Table #31429
Conversation
# test "the truth" do | ||
# assert true | ||
# end | ||
end |
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.
Do we keep these Rails auto generated files around even if we don't have any content in them?
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.
🤷♀ I was assuming that as I added things to the table I would probably need to use them for testing?
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, I didn't realize these were auto generated! Perhaps your first test can just make sure that we can create a user_level_info using the new factory method?
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.
Yay! I'm glad it worked. Way to persist through a tangly migration!
def change | ||
create_table :user_level_infos do |t| | ||
t.integer :time_spent, default: 0 | ||
t.bigint :user_level_id, unsigned: true |
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.
Please try this instead:
t.bigint :user_level_id, unsigned: true | |
t.references :user_level, foreign_key: true |
To do this, you will need to rollback the migration in its current state, change this code line, and then migrate forward again.
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.
This was failing yesterday because of the issue that is talked about here: rails/rails#30806 . When I asked in infra channel they said it was okay to move forward without the foreign_key.
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.
got it. they would know best! sounds good.
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.
apologies, Dani, one more request.
Hey there! I just saw this migration go in, and had a question about naming and documentation. Are we set on Something else that might help would be a comment at the top of |
@islemaster the current thinking is that UserLevelInfo is essentially an offshoot of UserLevel, for scalability and ease-of-development reasons. The size of |
👍 I'm totally on board with this approach! I just wanted to check that we have a plan for documenting it. I think it might not be obvious to somebody new to our code. |
@islemaster @davidsbailey Adding a comment in user_level_info.rb in #31592 |
Description
We want to record the amount of time that is spent on a certain level. Instead of adding a column on UserLevels this creates a new table where we will record the
time_spent
on a level as well as theuser_level_id
so that we can point back to the UserLevel when needed.Future work
Next will be using this table to start storing the time spent on a level.
Links
Testing story
Reviewer Checklist: