Add `DynamoDbClient dynamoDbClient()` to DynamoDbEnhancedClient interface

[cborison]

Describe the feature

Simply add the method DynamoDbClient dynamoDbClient() to DynamoDbEnhancedClient interface. It already exists on the DefaultDynamoDbEnhancedClient implementation.

Use Case

It is sometimes necessary to dive down into the raw client to perform queries that might not be supported at the enhanced client level (e.g. COUNT queries).

To avoid needing to pass around the DynamoDbClient directly (and avoid ugly casts like var client = ((DefaultDynamoDbEnhancedClient) enhancedClient).dynamoDbClient()) it would be helpful if the enhanced client interface provided the ability to retrieve the raw client (interface) used to build it.

The DynamoDbEnhancedClient.Builder already takes in the DynamoDbClient interface type -- is it possible we could also return that same object from the enhanced client interface?

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Java SDK version used

2.38.9

JDK version used

25

Operating System and version

macOS 15.7.2

[debora-ito]

@cborison count is supported in DynamoDB Enhanced Client queries via the returned Page.

Which other operations of the low-level client would you use that are not supported in the Enhanced client?

[cborison]

Thanks for the response!

I can get the count from the paged response, but does that entail the overhead of additional data returned from the query as well as the (minor) mapping overhead to build the response entities?

Assuming there is no extra bandwidth usage / overhead there -- it would still be a bit less trivial to use the returned Page on the enhanced client due to the lack of the helpful queryPaginator method (manual pagination to get a fully accurate count would be required assuming the limits are hit for the page size during the count).

Outside of my one contrived count example, though, I have still found it useful at times to use the raw client at times when you need very low level control over specific operations. As another example, hand rolling a targeted update expression against specific data without needing to retrieve the record first -- e.g. SET fieldA = fieldA + 1.

Edit: Perhaps a better example of a missing feature as well -- we also use polymorphic table design where a single table holds different (but related) types of entities sharing a common PK but separate SKs with a discriminator prefix. We need to rely on the raw client to execute queries and then manually map results (via TableSchema helpers) to the appropriate instance. I'm aware that there are already asks polymorphic support in the v2 enhanced client -- so I'm not really asking for that here 😄 .