-
Notifications
You must be signed in to change notification settings - Fork 66
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
[ARP POA submission] (#1) Create migration for PoA form submissions (#101919) #20499
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
class CreateArPowerOfAttorneyFormSubmissions < ActiveRecord::Migration[7.2] | ||
def change | ||
create_table :ar_power_of_attorney_form_submissions do |t| | ||
t.uuid :power_of_attorney_request_id, null: false | ||
t.string :service_id | ||
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 wonder if there is value to the DB being set up with a constraint that |
||
t.text :service_response_ciphertext | ||
t.string :status, null: false | ||
t.text :encrypted_kms_key | ||
t.datetime :status_updated_at | ||
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. Let's decide on whether we should use both 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 removed |
||
t.text :error_message_ciphertext | ||
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. Are we settled on this single error message or do we want a 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. It seems JSONB doesn't play well with ciphertext anyway, it's still requiring a string 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.
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. If all that is true maybe 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. And for your broader point that going with |
||
t.datetime :created_at, null: false | ||
end | ||
end | ||
end |
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.
We should make schema enforce the
has_one
which is something we've done elsewhere as well.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.
Would this be done using a
index: { unique: true }
? This would ensure only one form submission per PoA request? Will this not defeat the purpose of keeping errored records?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.
Yes, but I recall seeing platform guidance on OJ's last commit here to separate index creation (and run it "safely"). I don't know if they'll give us an exception for an empty table, I think this point has come up multiple times but I don't think I ever noticed their final point of view.
Anyway, if it is in a second migration, I don't know whether you'd get the nice inline syntax or not with a
change_column
statement or something like that, but if so, that would be the nice inline syntax.Good point. Thinking back to this comment in the ticket about how we're incrementally modeling towards generic form submission attempts elsewhere in the VA codebase:
Anyway, we don't have any imagined functionality or way for us as operators to initiate further attempts. A failed submission will be a terminal point of that POA request's lifecycle. Also, we'll be representing the same dumb thing to the frontend: one submission.