Port over table admin operations + remaining test infra - #7311
Open
RanVaknin wants to merge 5 commits into
Open
Conversation
|
This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This is almost entirely a dependency swap PR. The mapper's Table Admin API (createTable, deleteTable, describeTable, and the generateRequest builders) and its test infrastructure move from the v1 SDK (com.amazonaws.) to v2 (software.amazon.awssdk.*). Most of the diff is repetitive, new
X().withY(becomesX.builder().y().build(),.getX()becomes.x(), plus import changes.additionally, I marked
"skipImport": trueon the mapper module in thebrazil.jsonfile, so the SDK builds can run through (will get re-enabled in the near future)Two things are worth a closer look:
1. Null vs. empty collections
v1 collection getters return null when unset whereas v2 returns an empty collection and a separate
hasXxx()presence check, never null. So a == null check copied from v1 never fires on v2. Response side reads follow the v2 form throughout the port, and this PR is no exception.The only real UX impact could be if a user reads from
generateCreateTableRequest, which returns a low level v2CreateTableRequest. For a class with no GSIs,request.globalSecondaryIndexes()returns an empty list instead of v1's null. That empty list is the v2 client's own getter contract, identical for anyone calling v2 directly, and the mapper does not control it.2. Test infrastructure
The test framework and fixtures use
ddb.waiter().waitUntilTableExistsandwaitUntilTableNotExistsinstead of the old v1 TableUtils polling loops, and compare TableStatus by enum identity instead of string equality. One helper sets the GSI list only when it is non empty, because v2 createTable reject an explicitly empty GSI list that v1 accepted as unset.