Numeric type casting of attributes nested in maps

[linkyndy]

We have float_attr and map_attr definitions, however there seems to be no way of defining the types of attributes nested in maps. I am currently reading a float out of a map and the result is a BigDecimal (0.2997e2 instead of 29.97), as per DynamoDB's Ruby SDK.

Is there any way to address this?

[mullermp]

Thanks for opening an issue. I believe maps behave similar to JSON objects, and each key-value is unknown to aws-record. (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes). Can you share your code on how you're reading out the float out of your map? And can you confirm that 29.97 is what's stored in DynamoDB (check raw values and not parsed values by the Ruby SDK, by either checking the wire tracing logs or check console)?

[awood45]

This is definitely a limitation of a plain map_attr type, by not being opinionated about the map contents you fall back to the default SDK parsing - which is good, but not as detailed as the other marshalers. One thing to keep in mind is that you can make custom types and marshalers, so if you have a predictable map structure and want a more opinionated marshaling, writing your own custom type might be worthwhile.

…

On Apr 4, 2022, at 9:45 AM, Matt Muller ***@***.***> wrote:  Thanks for opening an issue. I believe maps behave similar to JSON objects, and each key-value is unknown to aws-record. (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes). Can you share your code on how you're reading out the float out of your map? And can you confirm that 29.97 is what's stored in DynamoDB (check raw values and not parsed values by the Ruby SDK, by either checking the wire tracing logs or check console)? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[linkyndy]

Thank you both for your answers.

Well, attributes (except the hash/sort keys) don't need to have a type, however aws-record allows you to define it for practical reasons. This is why I was curious why wouldn't it be possible for maps as well. 29.97 is actually stored in DynamoDB, yes.

A custom marshaller sounds indeed interesting, thank you for your suggestion.

This being said, are there no plans of supporting type declarations for map attributes?

[awood45]

aws-record itself is only defining types to allow for that more precise marshaling. The big issue as I see it, though a better idea could be proposed, is that having marshalers for each map type possible would create a lot of different marshalers, really. Especially where complex maps (arbitrary JSON, so mixed types) are a common use case.

…

On Tue, Apr 5, 2022 at 7:37 AM Andrei Horak ***@***.***> wrote: Thank you both for your answers. Well, attributes (except the hash/sort keys) don't need to have a type, however aws-record allows you to define it for practical reasons. This is why I was curious why wouldn't it be possible for maps as well. 29.97 is actually stored in DynamoDB, yes. A custom marshaller sounds indeed interesting, thank you for your suggestion. This being said, are there no plans of supporting type declarations for map attributes? — Reply to this email directly, view it on GitHub <#120 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQEHIM5B7MOARMVAEOCL3TVDRFZVANCNFSM5SPZN7IA> . You are receiving this because you commented.Message ID: ***@***.***>

[mullermp]

Well you can certainly call to_f on BigDecimal if you'd like to work with floats. It seems that DynamoDB has a very large number range and doesn't have a concept of integer or float, just "number" where BigDecimal is a catch-all.

[linkyndy]

What I had in mind, was something along the lines of:

string_attr :foo
map_attr :bar do
  float_attr :baz
end

Attributes not defined inside a map would resort to the defaults, same as the attributes defined at the model level. This won't require any new marshaller, rather than recursively marshall nested attributes using the known marshallers (there's a finite list of types that can be nested inside a map).

[mullermp]

Related to #96