-
Notifications
You must be signed in to change notification settings - Fork 33
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
BFD-3881: IDR beneficiary model updates #2566
base: master
Are you sure you want to change the base?
Conversation
CREATE TABLE idr.beneficiary( | ||
bene_sk BIGINT NOT NULL PRIMARY KEY, | ||
bene_xref_efctv_sk BIGINT NOT NULL, | ||
bene_xref_efctv_sk_computed BIGINT NOT NULL GENERATED ALWAYS |
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.
There's some weird behavior with bene_xref_efctv_sk
that causes the potential need for this column. Sometimes that field is set to 0 in which case we need to fall back to using bene_sk
for joins. Joining on a case statement is very bad for performance, so computing this value ahead of time will make it possible to filter on these values. This requirement may change as we learn more.
last_timestamp TIMESTAMPTZ NOT NULL | ||
); | ||
|
||
CREATE MATERIALIZED VIEW idr.overshare_mbis AS |
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.
There is exactly 1 instance in IDR where an MBI is assigned to more than one person. This is an extreme edge case, but we should still do our best to protect against overshares, so we can store these in a way that makes them easy to filter out.
JIRA Ticket:
BFD-3881
What Does This PR Do?
What Should Reviewers Watch For?
If you're reviewing this PR, please check for these things in particular:
What Security Implications Does This PR Have?
Please indicate if this PR does any of the following:
Adds any new software dependencies
Modifies any security controls
Adds new transmission or storage of data
Any other changes that could possibly affect security?
I have considered the above security implications as it relates to this PR. (If one or more of the above apply, it cannot be merged without the ISSO or team security engineer's (
@sb-benohe
) approval.)I have created tests to sufficiently ensure the reliability of my code, if applicable. If this is a modification to an existing piece of code, I have audited the associated tests to ensure everything works as expected.
Validation
Have you fully verified and tested these changes? Is the acceptance criteria met? Please provide reproducible testing instructions, code snippets, or screenshots as applicable.
Unit/integration tests