dynamodb example expects attributes

[lpschroer]

Describe the issue

Dear Contributors,

I have come upon this example when using the dynamodb rust SDK. It seems to me that some return values are expected in the default case here, i.e. when .set_return_values(None). However, the actual behavior is that nothing is returned in the response object for key attribute, compare PutItemOutput { attributes: None, .... This behavior is in agreement with the API documentation.

NONE - If ReturnValues is not specified, or if its value is NONE, then nothing is returned. (This setting is the default for ReturnValues.)

The idea to have your new item returned as a response is nice, but if it does not work it makes it harder to engage with the example, which is why I would propose to change the example accordingly and prevent confusions.

I would also like to mention, that using other enum values, e.g. .set_return_values(Some(ReturnValue::AllNew)), will not result in a compile time, but a runtime error. I would suspect this behavior to be unfavored and unnecessary. I do not consider this to be an error, but I would say it is "error-adjacent" considering the type safety attitude of the language.

Am I missing something here?

Thanks!

Links

• https://docs.rs/aws-sdk-dynamodb/1.56.0/aws_sdk_dynamodb/operation/put_item/builders/struct.PutItemFluentBuilder.html#method.return_values

• aws-sdk-rust/examples/examples/dynamodb/src/scenario/add.rs

  Line 46 in 9d3959a

  let attributes = resp.attributes().unwrap();

[landonxjames]

Thanks for bringing this to our attention! We will get the example updated.

I would also like to mention, that using other enum values, e.g. .set_return_values(Some(ReturnValue::AllNew)), will not result in a compile time, but a runtime error. I would suspect this behavior to be unfavored and unnecessary. I do not consider this to be an error, but I would say it is "error-adjacent" considering the type safety attitude of the language.

Am I missing something here?

You are not missing anything, unfortunately there is no way for us to state anything about how properties set on an OperationInput type will impact the properties on the related OperationOutput type. That information is not contained in the model that the SDK is generated from.