[DynamoDbEnhancedClient] Support to flatten a Map into top level attributes of the object.

[ghost]

In my usecase, my dynamodb table has a fixed set of fields which are defined as fields in the class. There are a arbitrary fields which are represented by a Map<String, String>. I need the ability to use @DynamoDbFlatten on the Map similar to using it on a class.

Describe the Feature

Support @DyanmoDbFlatten annotation for Map as well.

Is your Feature Request related to a problem?

Without this feature I won't be able to use DynamoDbEnhancedClient

Proposed Solution

Describe alternatives you've considered

The only alternatives to this I can think of is to not use the DynamoDbEnhanced client at all.

Additional Context

The table we use has a fixed fields which can be represented using class members. However, there are arbitrary set of top level fields which need to be returned in a Map.

• [ ] I may be able to implement this feature request

Your Environment

• AWS Java SDK version used:
• JDK version used:
• Operating System and version:

[debora-ito]

@rakshith-vzm thank you for reaching out, sorry for the delayed response. Marking as a feature request.

[DianaElenaGusa]

Hi! I am interested in working on this issue and, after conducting an initial analysis, I have identified some key areas that require clarification regarding the expected behavior of @DynamoDbFlatten for Map types in V2. To ensure the implementation aligns with the intended design, I would like to clarify the following points.

Findings from V1

• In V1, Map types are stored as a single JSON object within a column. The column name corresponds to the map attribute's name, and the value contains the serialized JSON.
• Unlike nested objects, there is no mechanism in V1 to dynamically create columns based on map keys.

Expected Behavior in V2 My understanding is that V2 aims to introduce a new annotation that enables flattening maps by dynamically adding attributes/columns to the table schema. Specifically:

• Each key in the map would become a column name, with its corresponding value stored as the column value.
• However, this raises several design considerations that require clarification.

Key Questions

1. Dynamic Column Creation

• Should the new annotation support dynamically adding attributes/columns based on the keys in the map?

2. Handling Multiple Maps in a Model

• Can multiple maps exist in a single model?
• If so, how should deserialization work?
• A major challenge is that dynamically generated attributes may not have a clear association with a specific map if multiple maps exist in the model.

3. Supported Map Types

• Should this feature support only Map<String, String>? Or should it extend to Map<String, Object>?

Potential Deserialization Approaches There are two possible strategies for handling deserialization, each with trade-offs:

1. Dynamic Attribute Parsing (Flexible but Complex)

• Extract all attributes during deserialization.
• Any attribute not explicitly declared in the model is assigned to the map.
• Constraints: This approach may require limiting models to a single map per entity to avoid ambiguity. Larger maps could lead to significant number of columns in the dynamoDb table and could possibly break the 400 KB item size limit.

2. Predefined Column Mapping (Predictable but Restrictive)

• Expect column names to be predefined and explicitly mapped to known keys (e.g. as attributes={} parameter in the annotation definition).
• This approach will allow the definition of multiple maps in a single model.
• During deserialization, only known attributes are mapped back into the map.
• Limitation: Reduces flexibility since all potential keys must be predefined, requiring exception handling when a new key appears.

Conclusion These points need further clarification to ensure the implementation aligns with the expected behavior and avoids ambiguity. Could you please provide guidance on the intended behavior?

[debora-ito]

Implemented via #6102 and released in version 2.37.1. Closing.

[github-actions[bot]]

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.