Skip to content

Conversation

@ianbotsf
Copy link
Contributor

Issue #

#472

Description of changes

This PR refactors the converter interfaces used in DynamoDB Mapper to improve their semantics, composability, and reusability based on learnings from Dev Preview. Notable improvements:

  • Converter data are no longer referenced in terms of "from" and "to", which inaccurately portrayed converters as unidirectional. Now, data are referenced in terms of "left" and "right". By convention, "left" refers to data types which are closer to the caller's business logic (e.g., high-level Kotlin objects) while "right" refers to data types which are farther from the caller's business logic (e.g., DynamoDB Item/AttributeValue instances).
  • Converters are now chained with the +/plus operator rather than andThenTo which also inaccurately conveyed unidirectionality.
  • Removed SplittingConverter which was a confusing and overly-complex construct. Also removed the related class Either.
  • The names of converter implementations in DynamoDB Mapper now explicitly include ItemConverter or ValueConverter to disambiguate the type of object handled.
  • ItemConverter no longer contains a conversion overload for limiting the set of attributes to be converted, which is now handled exclusively by Item.intersectKeys. ItemConverter is now a straightforward typealias ItemConverter<T> = Converter<T, Item>.

Review guide

There are a lot of changes in this PR but many are renames and moves. I'd advise skimming the codegen changes but paying more attention to changes in :hll-mapping-core and :dynamodb-mapper. In particular, I recommend proceeding in this fashion:

  1. The new README.md in :hll-mapping-core
  2. The converter/monoconverter implementations in :hll-mapping-core
  3. The updated converter implementations in :dynamodb-mapper

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@ianbotsf ianbotsf requested a review from a team as a code owner November 14, 2025 19:44
@github-actions
Copy link

A new generated diff is ready to view.

  • No codegen difference in the AWS SDK

@ianbotsf ianbotsf added the acknowledge-api-break Acknowledge that a change is API breaking and may be backwards-incompatible. Review carefully! label Nov 17, 2025
@github-actions
Copy link

A new generated diff is ready to view.

  • No codegen difference in the AWS SDK

@ianbotsf ianbotsf added the no-changelog Indicates that a changelog entry isn't required for a pull request. Use sparingly. label Nov 17, 2025

![](docs/img/element-mapping-converter.png)

Collection converters are typically build using factory functions which accept one or more delegate converters as
Copy link
Contributor

Choose a reason for hiding this comment

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

Correctness: build -> built

val byteToLong: Converter<Byte, Long> = byteToShort + shortToInt + intToLong
```

### Element mapping
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: The Element mapping section is missing an example of a ListMappingConverter implementation

@@ -0,0 +1,146 @@
# HLL Converters
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a really cool write up!

Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: On naming (ListMappingConverter and the rest of the collection converters). Adding an s at the end of the file name to prevent people for looking for xConverter and xMonoConverter in different files.

if (existingImport == null) {
imports += ImportDirective("${type.pkg}.${type.baseName}")
} else if (existingImport.fullName != type.fullName) {
} else if (existingImport.fullName != "${type.pkg}.${type.baseName}") {
Copy link
Contributor

Choose a reason for hiding this comment

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

Question: Why this change?

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

Labels

acknowledge-api-break Acknowledge that a change is API breaking and may be backwards-incompatible. Review carefully! no-changelog Indicates that a changelog entry isn't required for a pull request. Use sparingly.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants