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

Create UserLevelInfo Table #31429

Merged
merged 7 commits into from Oct 29, 2019
Merged

Create UserLevelInfo Table #31429

merged 7 commits into from Oct 29, 2019

Conversation

dmcavoy
Copy link
Contributor

@dmcavoy dmcavoy commented Oct 23, 2019

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 the user_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:

  • Tests provide adequate coverage
  • Code is well-commented
  • New features are translatable or updates will not break translations
  • Relevant documentation has been added or updated
  • User impact is well-understood and desirable
  • Pull Request is labeled appropriately
  • Follow-up work items (including potential tech debt) are tracked and linked

# test "the truth" do
# assert true
# end
end
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Member

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?

Copy link
Contributor

@Erin007 Erin007 left a 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!

dashboard/test/factories/user_level_infos.rb Outdated Show resolved Hide resolved
dashboard/test/models/user_level_info_test.rb Outdated Show resolved Hide resolved
def change
create_table :user_level_infos do |t|
t.integer :time_spent, default: 0
t.bigint :user_level_id, unsigned: true
Copy link
Member

Choose a reason for hiding this comment

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

Please try this instead:

Suggested change
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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

@davidsbailey davidsbailey left a 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.

dashboard/test/factories/user_level_infos.rb Outdated Show resolved Hide resolved
@dmcavoy dmcavoy merged commit 217fd8f into staging Oct 29, 2019
@dmcavoy dmcavoy deleted the lets-make-this-table branch October 29, 2019 17:18
@islemaster
Copy link
Contributor

Hey there! I just saw this migration go in, and had a question about naming and documentation.

Are we set on UserLevelInfo as a name for this new model? UserLevel and UserLevelInfo are very similar, and I'm not sure I'd understand why they both exist based on the names alone.

Something else that might help would be a comment at the top of user_level_info.rb explaining the purpose of the model. (I've often wished we had these for PLC models.)

@davidsbailey
Copy link
Member

@islemaster the current thinking is that UserLevelInfo is essentially an offshoot of UserLevel, for scalability and ease-of-development reasons. The size of user_levels means that new, sparsely populated columns will consume an inordinate amount of resources, and it is also impractical to add new columns because doing so can cause site downtime. See some discussion here: #31231 and https://codedotorg.slack.com/archives/C03CK49G9/p1571072062117400

@islemaster
Copy link
Contributor

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

@dmcavoy dmcavoy mentioned this pull request Oct 30, 2019
7 tasks
@dmcavoy
Copy link
Contributor Author

dmcavoy commented Nov 1, 2019

@islemaster @davidsbailey Adding a comment in user_level_info.rb in #31592

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants