RHINENG-26116: create workspace-aware advisories aggregate table#2184
Open
rverdile wants to merge 4 commits into
Open
RHINENG-26116: create workspace-aware advisories aggregate table#2184rverdile wants to merge 4 commits into
rverdile wants to merge 4 commits into
Conversation
Reviewer's GuideAdds a new workspace-aware, partitioned account advisory aggregate table (account_advisory), wires it into schema creation, migration, test-data cleanup, and documentation, without yet integrating it into application logic. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 3 issues, and left some high level feedback:
- The
UNIQUE (advisory_id, rh_account_id, workspace_id)constraint onaccount_advisoryappears redundant with the primary key containing the same columns; if the different column order is intended to optimize specific query patterns, consider replacing the UNIQUE with an explicitly named index to make that intent clear. - Given expected access patterns, double-check whether additional indexes (e.g. starting with
advisory_idor includingnotified) are needed for common queries, since the current primary key and(rh_account_id, workspace_id)index may not cover lookups that are advisory-centric or notification-centric.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `UNIQUE (advisory_id, rh_account_id, workspace_id)` constraint on `account_advisory` appears redundant with the primary key containing the same columns; if the different column order is intended to optimize specific query patterns, consider replacing the UNIQUE with an explicitly named index to make that intent clear.
- Given expected access patterns, double-check whether additional indexes (e.g. starting with `advisory_id` or including `notified`) are needed for common queries, since the current primary key and `(rh_account_id, workspace_id)` index may not cover lookups that are advisory-centric or notification-centric.
## Individual Comments
### Comment 1
<location path="database_admin/schema/create_schema.sql" line_range="793-798" />
<code_context>
+ CONSTRAINT account_advisory_advisory_id
+ FOREIGN KEY (advisory_id)
+ REFERENCES advisory_metadata (id),
+ UNIQUE (advisory_id, rh_account_id, workspace_id),
+ PRIMARY KEY (rh_account_id, workspace_id, advisory_id)
+) PARTITION BY HASH (rh_account_id);
</code_context>
<issue_to_address>
**suggestion (performance):** The UNIQUE constraint duplicates the PRIMARY KEY and might be unnecessary.
The PRIMARY KEY on `(rh_account_id, workspace_id, advisory_id)` already enforces uniqueness for this column set, just in a different order. Unless you need this specific column order for query planning, you can remove the separate `UNIQUE (advisory_id, rh_account_id, workspace_id)` to avoid the overhead of an extra index.
```suggestion
CONSTRAINT account_advisory_advisory_id
FOREIGN KEY (advisory_id)
REFERENCES advisory_metadata (id),
PRIMARY KEY (rh_account_id, workspace_id, advisory_id)
) PARTITION BY HASH (rh_account_id);
```
</issue_to_address>
### Comment 2
<location path="database_admin/schema/create_schema.sql" line_range="809" />
<code_context>
+SELECT grant_table_partitions('SELECT, INSERT, UPDATE, DELETE', 'account_advisory', 'listener');
+SELECT grant_table_partitions('SELECT, INSERT, UPDATE, DELETE', 'account_advisory', 'vmaas_sync');
+
+CREATE INDEX ON account_advisory (rh_account_id, workspace_id);
</code_context>
<issue_to_address>
**suggestion (performance):** The separate index on (rh_account_id, workspace_id) may overlap with the primary key index.
The primary key on `(rh_account_id, workspace_id, advisory_id)` already provides a btree index that can serve most queries filtering on `(rh_account_id, workspace_id)`. Unless you have specific evidence that dropping `advisory_id` from the index is needed (e.g., for size or a particular query pattern), this extra index is likely redundant and could be removed to reduce write overhead and maintenance cost.
</issue_to_address>
### Comment 3
<location path="database_admin/migrations/153_account_advisory.up.sql" line_range="25" />
<code_context>
+SELECT grant_table_partitions('SELECT, INSERT, UPDATE, DELETE', 'account_advisory', 'listener');
+SELECT grant_table_partitions('SELECT, INSERT, UPDATE, DELETE', 'account_advisory', 'vmaas_sync');
+
+CREATE INDEX ON account_advisory (rh_account_id, workspace_id);
</code_context>
<issue_to_address>
**suggestion (performance):** Consider whether the (rh_account_id, workspace_id) index is needed in addition to the PK index.
Since the PK already starts with `(rh_account_id, workspace_id)`, this additional index likely duplicates it while adding insert/update overhead. Please confirm via query plans that it’s actually used; if not, consider removing it and relying on the PK index.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
MichaelMraka
requested changes
May 11, 2026
| FOREIGN KEY (advisory_id) | ||
| REFERENCES advisory_metadata (id), | ||
| UNIQUE (advisory_id, rh_account_id, workspace_id), | ||
| PRIMARY KEY (rh_account_id, workspace_id, advisory_id) |
Collaborator
There was a problem hiding this comment.
PK is, by definition, unique. So another unique index on the same columns is not necessary.
I'd also change order of columns in PK to (rh_account_id, advisory_id, workspace_id) because it can be also used to search 'prefixes'. And we will likely have some queries for rh_account_id + advisory_id and not for rh_account_id + workspace_id.
Actually PK is correct. Now with Kessel we always filter by rh_account_id and workspace_id so it make sense to have them first.
| SELECT grant_table_partitions('SELECT, INSERT, UPDATE, DELETE', 'account_advisory', 'listener'); | ||
| SELECT grant_table_partitions('SELECT, INSERT, UPDATE, DELETE', 'account_advisory', 'vmaas_sync'); | ||
|
|
||
| CREATE INDEX ON account_advisory (rh_account_id, workspace_id); |
Collaborator
There was a problem hiding this comment.
I don't know if this index is useful / necessary. Will we ever query something like "all advisories in given org and workspace"?
This is unnecessary because it's a prefix of already existing PK.
| ( | ||
| advisory_id BIGINT NOT NULL, | ||
| rh_account_id INT NOT NULL, | ||
| workspace_id TEXT NOT NULL, |
Collaborator
There was a problem hiding this comment.
workspace_id should be UUID. (takes less space)
adds a new table for account advisories by workspace, but does not wire-up the table to anything
rverdile
force-pushed
the
workspace-aware-table
branch
from
dbe91dd to
81054a1
Compare
rverdile
force-pushed
the
workspace-aware-table
branch
from
b26d520 to
8273ed8
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2184 +/- ##
=======================================
Coverage 59.06% 59.06%
=======================================
Files 136 136
Lines 8761 8761
=======================================
Hits 5175 5175
Misses 3040 3040
Partials 546 546
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Contributor
Author
|
thanks @MichaelMraka, updated! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
adds a new table for account advisories by workspace, but does not wire-up the table to anything
Secure Coding Practices Checklist GitHub Link
Secure Coding Checklist
Summary by Sourcery
Introduce a workspace-scoped advisory aggregation table and wire it into schema, migrations, and docs.
New Features:
Enhancements:
Build:
Tests: