-
Notifications
You must be signed in to change notification settings - Fork 166
Remove proofing costs report, associated data (LG-8028) #7345
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
| Original file line number | Diff line number | Diff line change | ||
|---|---|---|---|---|
|
|
@@ -2,9 +2,5 @@ class BackfillAddAcuantResultToProofingCosts < ActiveRecord::Migration[5.2] | |||
| disable_ddl_transaction! | ||||
|
|
||||
| def up | ||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A question from my own ignorance: Could we remove this migration file altogether?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Related question: We only need to do anything here because the Ruby class implemlentation wouldn't exist, right? So it's not a problem that other migrations would continue to reference the (later-deleted) tables, since they'd be present at that point in the migration timeline? identity-idp/db/primary_migrate/20220906112214_add_threatmetrix_to_proofing_cost.rb Line 5 in d5081da
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah exactly, it's because the Another option would have been to redo this as raw SQL because at the time it runs, the table would exist. I guess we could remove the class, but the timestamp slug would still exist in the Do you think it would be clearer to remove entirely?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was mostly curious to improve my understanding of the migrations, but I don't have a strong feeling one way or the other. I think practically speaking this is almost certainly something we won't need. I'd defer to what you think is best, and generally would be fine to keep it as-is.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok! Ill choose to leave it, because I think for future us, it's easier to look back at the history of a mostly empty file that does exist, rather than search history for a file that used to exist |
||||
| ProofingCost.unscoped.in_batches do |relation| | ||||
| relation.update_all acuant_result_count: 0 | ||||
| sleep(0.01) | ||||
| end | ||||
| end | ||||
| end | ||||
This file was deleted.
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'm a bit confused by what I'm seeing in #7346 changes, but just to confirm: The unused argument here is temporary during deployment, and we'll circle back to remove it and the Rubocop inline disabling?
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.
Yeah the two PRs got out of sync a bit as I was patching more issues
My current thinking is, maybe we don't want to remove the
user_idas an argument? Since if we ever wanted to add analytics logging, it would be useful to have, etc