It may not be "idiomatic", but it works best for me. Accelerate progress up the cloud curve with Cloud Academy's digital training solutions.
#LOCAL DYNAMODB GOLANG CODE#
For example, instead of using that expression builder, I populate the expression fields in QueryInput in code myself based on the language-neutral DynamoDB documentation. For example, the godoc for /aws/aws-sdk-go-v2/service/dynamodb/expression NewBuilder() explains that "NewBuilder returns an empty Builder struct", but doesn't really explain why there are ten Builder types (Builder, ConditionBuilder, KeyBuilder, NameBuilder, OperandBuilder, etc.), how you should use them together, or why.īecause of this gap in documentation and examples, I find myself fighting with the SDK the least if I stick to the language-neutral docs/API reference as much as possible. I’m going to shout my advice here so all can hear: Filter Expressions won't save your bad DynamoDB table design. partitionKey - the partition key attribute for the global secondary index. The props we have passed to the method are: indexName - the name of the global secondary index. we created a Global secondary index on the table using the addGlobalSecondaryIndex method.
Yet there’s one feature that’s consistently a red herring for new DynamoDB users filter expressions. we created a dynamodb table with provisioned capacity. You can find most things in autocomplete, once you get acclimated to how the API maps to the Go SDK (create an xxxInput, call svc.xxx(), use the service-specific /types packages for constants, etc.)ĭoing things where there is Go-specific wrapper code is a bit harder documentation-wise. Primary keys, secondary indexes, and DynamoDB streams are all new, powerful concepts for people to learn. My experience is that SDK v2 is easiest to use when you are working from the language-neutral AWS service API reference (for example, for Rekognition, these docs).
0 kommentar(er)
