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.

[lpschroer]

Nice, thank you for the clarification!

Ahh, that makes sense, thanks. Could the model be fixed though? Wouldn't this mean fixing it for other languages, also?

[landonxjames]

Could the model be fixed though? Wouldn't this mean fixing it for other languages, also?

Not really. Our modeling language Smithy doesn't support that type of cross-shape constraints. We could make a feature request to Smithy for something like that, but it would also complicate things like our backwards compatibility guarantee, so I think it is unlikely to be implemented. It is also (at least as far as I am aware) not something Rust supports modeling in an idiomatic way.

[lpschroer]

Hmm, alright, I think I'd have to understand better how smithy works to really follow the point you are making, but I think I get the gist. Nonetheless, thanks for the explanation! 👍 I look forward to the update.

Best wishes and have a happy new year!