json annotations are not supported in attributevalue.MarshalMap

[Cyberax]

Confirm by changing [ ] to [x] below to ensure that it's a bug:

• I've gone though the API reference
• I've checked AWS Forums and StackOverflow for answers
• I've searched for previous similar issues and didn't find any solution

Describe the bug
json annotations are not supported in attributevalue.MarshalMap. The only supported annotations are dynamodbav. This is a regression compared to the V1 SDK.

Version of AWS SDK for Go?
Example: v1.11.0, DDB: 1.7.0

Version of Go (go version)?
1.16

To Reproduce (observed behavior)

type SomeStruct struct{
    Id string `json:"id"`
}
s := SomeStruct{Id: "123"}
values, err := attributevalue.MarshalMap(&s)
// values will contain: {Id -> "123"} - note the upper case

Expected behavior
Return:

id -> "123"

[moogacs]

I have encountered the same bug which json tag is not respected when marshalling a struct and it has inconsistent behaviour that it's sometimes respected and sometimes not

go version v1.16
dynamodb v1.9.0 
aws sdk v1.11.1

[0DegreesKelvin]

Same bug for me after update to aws sdk v1.11.1

[jasdel]

Thanks for reaching out. The issue you're experiencing is the intended behavior of V2 SDK's AttributeValue (un)marshalers. The best way to configure the (un)marshalers to use alternative struct tags is to documented in the package's Overview

There are a few ways you can configure the (un)marshaler for the serialized id to use.

• add dynamodbav:"name" struct tag to fields
• Implement attributevalue.Marshaler with custom specification of conversion between Go type and AttributeValue.
• Specify EncoderOptions or DecoderOptions when creating an encoder specifying the struct tag that should be used for names.

[jasdel]

Issue, #1494 and PR #1495 help address the overall issue of configuring the (un)marshaler with alternative tagkeys.

[moogacs]

Thanks for your response @jasdel, I know those solutions and that what I am doing at the moment but
that is not what AWS documentation and source code says

// Tag key `dynamodbav` will always be read, but if custom tag key
// conflicts with `dynamodbav` the custom tag key value will be used.
TagKey string

type EncoderOptions struct {
	// Support other custom struct tag keys, such as `yaml`, `json`, or `toml`.
	// Note that values provided with a custom TagKey must also be supported
	// by the (un)marshalers in this package.
	//
	// Tag key `dynamodbav` will always be read, but if custom tag key
	// conflicts with `dynamodbav` the custom tag key value will be used.
	TagKey string

	// Will encode any slice being encoded as a set (SS, NS, and BS) as a NULL
	// AttributeValue if the slice is not nil, but is empty but contains no
	// elements.
	//
	// If a type implements the Marshal interface, and returns empty set
	// slices, this option will not modify the returned value.
	//
	// Defaults to enabled, because AttributeValue sets cannot currently be
	// empty lists.
	NullEmptySets bool
}

and the behaviour is inconsistent because, some times it marshals the structs correctly and sometimes not and that causes a lot of inconsistency in the databases

[moogacs]

@jasdel To proof what we are talking about, here a demonstration of different behaviours for the same pkg

case 1 :
IDLE case expected behavior using custom marshaler
https://go.dev/play/p/zoqHVu5tVjN

case 2 :
2 go routines do the same thing but one of them using custom tag marshaler and other is not and they lead to the same results
https://go.dev/play/p/HvpkhgDUl63

case 3 :
simply case 2 without go routines and it seems the custom tag marshaler doesn't work and affected by the other one
https://go.dev/play/p/ruZGAaWAgtx

all what you need to look at the printed keys Data and UserID

[jasdel]

I've created #1569 to track the issue with the SDK's DDB attribute value marshaler inconsistently serializing struct field names. Lets track that issue, and close this one. since this issue focused on the original feature to provide options to attributivevalue's (un)marshalers for TagKeys.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.