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.)
When linked resource had has_many links, all of them would use the
association from the first resource, causing all of the items to build
`links` with the same associations.
This fixes it by iterating over the serializers, not just the
attributes array.
If type is `author` but the association is called `writer`, the linked
resource key should be called `authors`, e.g
{
...
linked: {
authors: [{
...
}]
}
...
}
Currently, doing `include: author.bio` would work correctly, but not for
has_many associations such as `include: author.roles`. This fixes it.
The problem was basically that we were not handling arrays for has_many linked,
as happens for ArraySerializers.
