-
Notifications
You must be signed in to change notification settings - Fork 11
FlatPostgresCollection createOrReplace #268
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
FlatPostgresCollection createOrReplace #268
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #268 +/- ##
============================================
- Coverage 80.70% 80.44% -0.26%
- Complexity 1394 1396 +2
============================================
Files 239 239
Lines 6529 6598 +69
Branches 601 605 +4
============================================
+ Hits 5269 5308 +39
- Misses 868 888 +20
- Partials 392 402 +10
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:
|
| throw new RuntimeException("Invalid JSON format: 'statements' array not found"); | ||
| } | ||
|
|
||
| try (Connection connection = pgDatastore.getPostgresClient()) { |
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.
just a clarification, will this cause connection close each time we are done running these statements?
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, it's AutoCloseable. Is that a concern?
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.
so connection closed after every query/transaction? We barely utilize persistent connections?
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.
This is just a test case, we use a pooled connection in prod: https://github.com/hypertrace/document-store/pull/268/changes#diff-cb9cc13ae5f1676784171b330150156520fddb54ead6945e5494e6b62f17da50R695
| * @return optional of the primary key column name, or empty if no primary key is found | ||
| */ | ||
| @Override | ||
| public Optional<String> getPrimaryKeyColumn(String tableName) { |
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.
Are we assuming that we can't have composite primary keys? We just have to make it explicit and ensure the assumption is carried forward everywhere and the client's must be aware of it.
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.
Currently, we only have a single impl of Key : SingleValueKey. I will document this for now. Ultimately, we can pick up support for composite keys.
…g_write_createOrReplace
Description
Key Changes:
createOrReplaceforFlatPostgresCollection: This handles upserts for flat postgres collections. The SQL is generated as:If there's a conflict on the PK column, it basically references values from the "excluded" row (
EXCLUDEDis a special table that references the row that would have been inserted had there been no conflict).RETURNING (xmax = 0) AS is_insertbasically returns a 0 is it was an insert, or a 1 if it was an update. This helps us to differentiate b/w inserts and updates, which is also what thecreateAndReturnAPI returns.Handles primary keys properly: The system now queries the schema registry for the PK column. If it's unable to find it, it fallbacks to they
keycolumn that is hardcoded.Adds a
MissingColumnStrategy.defaultStrategy()that isSKIPcurrently.