Skip to content

Port operations - #7250

Draft
RanVaknin wants to merge 2 commits into
feature/master/DDB-mapperv2from
rvaknin/port-operations
Draft

Port operations#7250
RanVaknin wants to merge 2 commits into
feature/master/DDB-mapperv2from
rvaknin/port-operations

Conversation

@RanVaknin

Copy link
Copy Markdown
Contributor

No description provided.

segmentScanRequest = segmentScanRequest.toBuilder().exclusiveStartKey(lastScanResult.lastEvaluatedKey()).build();
} else {
segmentScanRequest.setExclusiveStartKey(null);
segmentScanRequest = segmentScanRequest.toBuilder().exclusiveStartKey(null).build();

@RanVaknin RanVaknin Aug 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unavoidable performance hit. v1's ScanResult was mutable and exposed direct setter. v2's ScanResponse is immutable and we are required to use .toBuilder() to reconstruct and mutate it.

@RanVaknin RanVaknin changed the title Rvaknin/port operations Port operations Aug 11, 2026
pause(batchLoadStrategy.getDelayBeforeNextRetry(batchLoadContext));
batchGetItemRequest.setRequestItems(
batchGetItemResult.getUnprocessedKeys());
batchGetItemRequest = batchGetItemRequest.toBuilder()

@RanVaknin RanVaknin Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor performance hit. BatchGetItemRequest gets reconstructed at every iteration because its immutable, and requires a .toBuilder()...build().

This codepath only fires when a batch request returns a response with unprocessedKeys: [a,b,c] for the mapper to retry. So it's at least not the hot path of every batch request.

return resultSet;
}

private static Map<String, KeysAndAttributes> buildKeysAndAttributes(

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

v1 grew each table's key list in place via requestItems.get(tableName).getKeys().add(x) because v1's KeysAndAttributes was mutable.

In v2 it's immutable, so the loop accumulates raw keys in a plain Map<String, List<Map<String, AttributeValue>>> and this helper builds each table's KeysAndAttributes once, at each processBatchGetRequest call (the 100 key boundary and the final partial batch)


AttributeValueUpdate update = updateValues.get(entry.getKey());
if (update != null) {
update.getValue()

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AttributeValueUpdate is immutable in v2, so instead of mutating the existing update's value in place we rebuild it with the transformed value via toBuilder().value(...).build()

public void disabled() {
}

// This record written by the .NET mapper no longer exists, so this test

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is removed because it was already non functional in v1. No coverage is lost

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant