fix(event-sources): handle dynamodb null type as none, not bool

[michaelbrewer]

Issue #, if available:

• Null type becomes BOOL #928

Description of changes:

Return for None for null types:

Example:

{
  "Records": [
    {
      ...
      "dynamodb": {
        "OldImage": {
          ...
          "Message": {
            "S": "New item!"
          },
          "Id": {
            "N": "101"
          }
        },
        "Keys": {
          "Id": {
            "N": "101"
          }
        },
        "NewImage": {
          ...
          "Message": {
            "NULL": true
          },
          "Id": {
            "N": "101"
          }
        },
      }
    }
  ]
}

Below null_value and get_value would have returned True, and now they return None.

from aws_lambda_powertools.utilities.data_classes import event_source
from aws_lambda_powertools.utilities.data_classes.dynamo_db_stream_event import (
    DynamoDBStreamEvent,
)

@event_source(data_class=DynamoDBStreamEvent)
def handler(event: DynamoDBStreamEvent, context):
    record = next(event.records)
    message_value = record.dynamodb.new_image.get("message")

    # get_value would be the preferred way to get the underlying value regardless of type
    assert message_value.get_value is None

    # Otherwise when you want to use `null_value` you should first change against `get_type`
    if message_value.get_type == AttributeValueType.Null:
        assert message_value.null_value is None

Checklist

• Meet tenets criteria
• Update tests
• Update docs
• PR title follows conventional commit semantics

Breaking change checklist

Before null_value was returning a boolean, True when NULL value was set to true and False when NULL value was not set (or was False)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov-commenter]

Codecov Report

Merging #929 (e49a858) into develop (cced6c4) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop     #929      +/-   ##
===========================================
- Coverage    99.88%   99.88%   -0.01%     
===========================================
  Files          118      118              
  Lines         5272     5271       -1     
  Branches       605      605              
===========================================
- Hits          5266     5265       -1     
  Misses           2        2              
  Partials         4        4              

Impacted Files	Coverage Δ
...s/utilities/data_classes/dynamo_db_stream_event.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cced6c4...e49a858. Read the comment docs.

[heitorlessa]

shouldn't this be True?

https://github.com/boto/boto3/blob/7a10e21c452e0cb0a6e3d245f7389f1500d2abcf/tests/unit/dynamodb/test_types.py#L69

[michaelbrewer]

@michaelbrewer - We are deserializing, {"NULL": False} should never happen (so should we raise a ValueError or just ignore that?)

[michaelbrewer]

@heitorlessa - i can remove that test, i just wanted it to be clear that we don't valid

    @property
    def null_value(self) -> None:
        """An attribute of type Null.

        Example:
            >>> {"NULL": True}
        """
        return None

[michaelbrewer]

which is the same as:

    def _deserialize_null(self, value):
        return None

[heitorlessa]

Question on whether NULL will ever be False, boto tests always caters for True

Type table only considers True so perhaps DynamoDB doesn't compute that: https://github.com/boto/boto3/blob/cf62d26cb0f28357c935d541ed3f0dae196cd26d/boto3/dynamodb/types.py#L85

[michaelbrewer]

Question on whether NULL will ever be False, boto tests always caters for True

Type table only considers True so perhaps DynamoDB doesn't compute that: boto/boto3@cf62d26/boto3/dynamodb/types.py#L85

Because boto does not allow you to call _deserialize_null directly but we allow for it via null_value