Fix DynamoDB property converter precedence when a global converter is…

[aanton-git]

Description

There is a bug in the AWS .NET SDK’s DynamoDB object persistence model where property-specific converters (defined via the DynamoDBProperty(Converter = …) attribute) are ignored if a global converter is already registered in the DynamoDBContext.ConverterCache. The global converter takes precedence even when a property has its own converter defined, which is unexpected behavior and contrary to how attribute-based converters should work. ([https://github.com//issues/4036][1])

Motivation and Context

Current Behavior
When using:

• A global converter registered via context.ConverterCache.Add(typeof(T), converter), and
• A per-property converter specified with the DynamoDBProperty(Converter = typeof(...)) attribute,
  the SDK always picks the global converter first, ignoring the more specific property converter. ([https://github.com/DynamoDB property attribute converter is ignored if global type converter is already registered #4036][1])

Expected Behavior
Property-specific converters should take precedence over globally registered converters. That is:

1. If a property has a converter attribute defined, use that.
2. Otherwise, fall back to a global converter from the converter cache. ([GitHub][1])

Testing

Breaking Changes Assessment

1. Identify all breaking changes including the following details:

Screenshots (if appropriate)

Types of changes

• [ x] Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• [x ] I have added tests to cover my changes
• [ x] All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[normj]

There is the small possibility users possibly unintentionally depended on the current behavior. I think making the fix is the right choice but for transparency can you add [Breaking Change] as a prefix to the log message.

[aanton-git]

Updated

[normj]

Sent branch into internal validation build. Assuming it passes then I'll approve the PR.

[normj]

Dry run f6febb1d-c996-4615-95bd-93d0770141a7 was successful