We need a Rake task that will iterate through all existing logged in kudos and fill in the empty user ID column. Note:
The task should not touch guest kudos (have IPs but no pseud IDs).
The task should not touch orphaned kudos (from deleted accounts: no pseud IDs, no IPs). We don't know what user ID to use anyway.
The task should account for pseud IDs that no longer exist. We don't have foreign key constraints here so this is possible. Don't bother scrubbing the leftover pseud ID, as we'll remove that column in the end.
The task should process kudos in batches and sensibly print its progress... it's a pretty big table.
How to test: this will be mostly on Rake specs. Admins should run this on staging (but after gets to staging). Check that the number of kudos without user IDs go down, and that the remaining ones are indeed either guest or orphaned.
On beta, similarly this task should be run after is also deployed.
Deployed to staging, but needs to be run to test it.
So, this is fun!
We ran this task on temporary staging, not actual staging. Then we ran the migration to BIGINT on actual staging without having run this. So now that is deployed to staging, no names are showing up for old kudos.
Running this task doesn’t work because it keeps running into duplicates, e.g.
ao3app@test-app13:~/app/current$ bundle exec rake After:add_user_id_to_kudos
Updating 232039 users' kudos in 233 batches
ActiveRecord::RecordNotUnique: Mysql2::Error: Duplicate entry '181741-Work-24' for key 'index_kudos_on_commentable_and_user': UPDATE `kudos` SET `kudos`.`user_id` = 24 WHERE `kudos`.`pseud_id` = 28 AND `kudos`.`user_id` IS NULL
We’re going to need to migrate down to get rid of the uniqueness constraint added in , then run this task, then migrate back up.
We migrated down AO3-5869, ran the task, then migrated up again. Registered kudos are back on the current staging server.