The User model currently lacks a first_name and last_name property, which limits the amount of information that can be stored and displayed for each user.
Due to the small table we have, this can be done entirely via 1 migration (single PR). When you create the design doc for this, please do talk about the different tradeoffs of doing this directly via a migration and any other ways this could be handled (if for instance we had a bigger table).
Currently there are two proposed method options for adding the first_name and last_name columns to the users table.
Active Record Migration
bin/rails generate migration AddNamesToUser first_name:string last_name:string
PROS - Adds the two required columns all in the same migration.
CONS- The need to backfill for existing users.
After the migration is completed, but prior to running the migration I propose to manually add a default modifier which will back fill all existing users with default values. In addition, we would set the Null flag to false thereby making these two fields required for future users.
For the existing users, I propose that each users changes their first_name and last_name independently from the console given the limited amount of users for which this applies.
Create a new ActiveRecord migration titled AddNamesToUser. The migration will create a change method for the migration, and add the two add_column statements, to add first_name and last_name columns to the User table.
Completing this database change via an Active Record migration is an appropriate approach to achieve the change goal. Writing and executing a schema modification statement in pure SQL would be a little more difficult to implement, as this statement has to be ran in the console (Which is a concern, and possibly an access concern for several developers on the team).
Additionally, the ActiveRecord migration approach with it’s built in functionality for this type of table change would work well in this case, and in the future when the data in the table grows larger. I suspect that the schema modification statement in SQL is likely to be a more resource intensive approach for larger tables.
You’ll have to split this in 3 PR’s
PR1: this pr will only include the migration file
PR2: backfill users.
PR3: Add client side code. Any changes you do to the controllers, views and models.