Marshall ruby Symbols as Strings for attribute values

[wal]

Allow ruby Symbols as attribute values, converting them to string representation within the AWS::DynamoDB::AttributeValue::Marshaller

DynamoDB does not have a native Symbol type and so these values are un-marshalled as Strings. Is this acceptable ?

This issue manifests itself if you attempt to save a ruby hash containing symbols as values .. e.g

dynamo_client.put_item(table_name: dynamodb_table_name, item: {hash: 'my-hash', value: :symbol_value})

will throw the error

unsupported type, expected Hash, Array, Set, String, Numeric, IO, true, false, or nil, got Symbol

[coveralls]

Changes Unknown when pulling dbd3b72 on wal:symbols_as_strings_attribute_value into * on aws:master*.

[trevorrowe]

I'm not against exploring this. When this was implemented initially, I purposefully chose to not support types that DynamoDB did not explicitly support. For example, DynamoDB does not have a native date or time attribute value. If I had made a customization to marshal ruby Time objects to a string value under a certain format then I would not be able to migrate to the new DynamoDB time attribute value without forcing users to migrate data.

Another consideration is that you will not be able to round-trip a hash with symbolized values and get back an equivalent hash. The values will have been stringified. This is probably okay, but it might surprise some users.

Generally, I think that Symbol is safe from having DynamoDB implement a native attribute value type.

Thoughts?

[trevorrowe]

Ping. Any comments?

[trevorrowe]

Sorry for sitting on this for so long. I've decided to merge this in. I don't see any possible path that DynamoDB could add a type that would need to map directly to a Ruby Symbol, leaving this open for string values. The SDK will however never attempt to symbolize strings on the way back out. This is for connivence, on setting values as they will not round-trip as symbols.

Thanks for the contribution.

[wal]

Thanks @trevorrowe