Support for HashWithIndifferentAccess / Symbolized Keys

[thomaswitt]

One of the predominant use cases of this SDK is IMHO writing Rails applications. Therefore it would make sense that this SDK supports Rails conventions as much as much as possible. Unfortunately it doesn't do that currently in term of keys as symbols vs strings.

The desirable version
map_attr :my_data, default_value: { items: [] }

throws an error while, as the syntax required is
map_attr :my_data, default_value: { 'items' => [] }.

Same for ERB:
<% my_data.except(:name).keys.each do |key| %>

does not work but needs to be
<% my_data.except("name").keys.each do |key| %>

This is very un-rails-y, both in models as in views, as using HashWithIndifferentAccess gives you at least both options. If you don't want to support this out of the box due to the dependency to ActiveSupport, I would at least making an option when ActiveSupport is available (or automatically use it).

[alextwoods]

Adding this as a feature request.

We don't want to take a dependency on ActiveSupport since this is rails-agnostic and often used outside of the context of rails. However, this seems like reasonable behavior to support and I see two options to do so:

1. We can add a new configuration option to the map_attr that allows you to specify the class used, eg: map_attr :my_data, klass: ActiveSupport::HashWithIndifferentAccess. This requires explicit configuration to opt into.

2. We patch the MapMarshaler in aws-sdk-rails to automatically use HashWithIndifferentAccess. aws-sdk-rails already contains a number of convenience features that make using the SDK easier in the context of rails, so this might reasonably fit in that context.

The patch (which you could also apply in your own code) would look something like:

module IndifferentMapMarshaler
  def type_cast(raw_value)
    ActiveSupport::HashWithIndifferentAccess.new(super)
  end
end

Aws::Record::Marshalers::MapMarshaler.extend(IndifferentMapMarshaler)

[thomaswitt]

@alextwoods I would vote for Option 2 as it seems to me the more flexible Option - and it doesn't require configuration, which is an added bonus. Thanks for the patch and pointing out to the piece of code.

[thomaswitt]

Just as a heads up, I am using that code since several months and it works really fine. So I can only encourage you to include it in the Gem.

[thomaswitt]

Hi @alextwoods - any progress regarding the configuration option?

[mullermp]

We have not prioritized aws-record work right now. Does the patch still work for you? I think as far as options go, we could implement a klass option like above or consider this for aws-record-rails.

[thomaswitt]

@mullermp that's sad to hear (regarding deprioritize aws-record, I'll write a bit more to that in issue 143).

The patch works only partly. It doesn't throw an error anymore, so that's good. But it's not a full support lf HashWithIndifferentAccess which leads to the problem that I always have to differ between symbols and strings in the code when having a map_attr.

Example (which the patch already in place):

class Input
  include Aws::Record
  map_attr :data
end

result = Input.create(data: { 'test1' => 'test2', 'test3' => { 'test4' => 'test5', 'test6' => 'test7' } } )
>> result.data
=> {"test1"=>"test2", "test3"=>{"test4"=>"test5", "test6"=>"test7"}}
>> result.data['test1']
=> "test2"
>> result.data[:test1]
=> nil

As you see, that is really a pity and led to many weird errors in the code when there's nil where a value should be and then you realize, ah, it's a map attr, so I can't use symbols anymore. I would really appreciate a solultion (at least with aws-record-rails) where all map_attr hashes can be HashWithIndifferentAccess.

Best,

Thomas