Comparing as a JSON string vs. as the Hash that is convert to JSON
works around the different Hash representations.
This likely has to do with the introduction of
config.action_dispatch.perform_deep_munge in Rails 4.1
See Rails issue 13420
1) Failure:
ActiveModel::Serializer::Adapter::Json::HasManyTestTest#test_has_many_with_no_serializer
[active_model_serializers/test/adapter/json/has_many_test.rb:36]:
--- expected
+++ actual
@@ -1 +1 @@
-{:id=>42, :tags=>[{"attributes"=>{"id"=>1, "name"=>"#hash_tag"}}]}
+{:id=>42, :tags=>[{"attributes"=>{:id=>1, :name=>"#hash_tag"}}]}
2) Failure:
ActiveModel::Serializer::AssociationsTest#test_has_many_with_no_serializer
[active_model_serializers/test/serializers/associations_test.rb:74]:
--- expected
+++ actual
@@ -1 +1 @@
-[{"attributes"=>{"name"=>"#hashtagged"}}]
+[{"attributes"=>{:name=>"#hashtagged"}}]
It's an upgrade based on the new Cache implementation #693.
It allows to use the Rails conventions to cache
specific attributes or associations.
It's based on the Cache Composition implementation.
It's a new implementation of cache based on ActiveSupport::Cache.
The implementation abstracts the cache in Adapter class on a
private method called cached_object, this method is intended
to be used on Adapters inside serializable_hash method in order
to cache each instance of the object that will be returned by
the serializer.
Some of its features are:
- A different syntax. (no longer need the cache_key method).
- An options argument that have the same arguments of ActiveSupport::Cache::Store, plus a key option that will be the prefix of the object cache on a pattern "#{key}-#{object.id}".
- It cache the objects individually and not the whole Serializer return, re-using it in different requests (as a show and a index method for example.)
The options passed to the render are partitioned into adapter options
and serializer options. 'include' and 'root' are sent to the adapter,
not sure what options would go directly to serializer, but leaving this
in until I understand that better.
