This pull request modifies the RTV import to only process a record if it hasn't been logged in the rock_the_vote_logs table.
How should this be reviewed?
The code changes are pretty small, this PR mostly adds test coverage to ensure these changes work as expected. What's changed:
Create the rock_the_vote_logs entry after the ImportRockTheVoteRecord job has finished all of its tasks (either creating user or getting existing user and checking for updates + creating post or getting existing post and checking for updates)
Adds a RockTheVoteLog::getByRecord function to search for whether a row has been imported already
Adds a compound index to the rock_the_vote_logs table to optimize search
Extracts creating and updating posts into smaller createPost and updatePostIfChanged functions to improve readability of the handle function
Adds a RockTheVoteRecord helper, getPostDetails to easily find row details saved into a post.details string property
Any background context you want to provide?
It hasn't been a big deal to re-process a record thus far, because we only update a user or post if a given record has a Status column value with higher priority than the user's voter_registration_status field or their voter registration post's status field.
However, once we modify this job to update the SMS preferences for users we import -- it will be important to NOT re-import a row, as the user might unsubscribe from SMS by the time we re-import the row. Our automated import may end up fetching a row a second time, because we purposely look for rows 30 minutes before the last job finished -- in order to avoid potentially missing rows in between jobs (see #139).
What's this PR do?
This pull request modifies the RTV import to only process a record if it hasn't been logged in the
rock_the_vote_logstable.How should this be reviewed?
The code changes are pretty small, this PR mostly adds test coverage to ensure these changes work as expected. What's changed:
Create the
rock_the_vote_logsentry after theImportRockTheVoteRecordjob has finished all of its tasks (either creating user or getting existing user and checking for updates + creating post or getting existing post and checking for updates)Adds a
RockTheVoteLog::getByRecordfunction to search for whether a row has been imported alreadyrock_the_vote_logstable to optimize searchExtracts creating and updating posts into smaller
createPostandupdatePostIfChangedfunctions to improve readability of thehandlefunctionAdds a
RockTheVoteRecordhelper,getPostDetailsto easily find row details saved into apost.detailsstring propertyAny background context you want to provide?
It hasn't been a big deal to re-process a record thus far, because we only update a user or post if a given record has a
Statuscolumn value with higher priority than the user'svoter_registration_statusfield or their voter registration post'sstatusfield.However, once we modify this job to update the SMS preferences for users we import -- it will be important to NOT re-import a row, as the user might unsubscribe from SMS by the time we re-import the row. Our automated import may end up fetching a row a second time, because we purposely look for rows 30 minutes before the last job finished -- in order to avoid potentially missing rows in between jobs (see #139).
Relevant tickets
Prep work for subscribing existing users in Pivotal #171848124.
Checklist