[wip] Fixes an issue with associations not passing options to ArraySerializer.

[jejacks0n]

for 0.10.0

• this simply allows ArraySerializer to determine what serializer to use if the option is passed.

I was unable to get a has_many association to render with a specific serializer, and was getting an undefined new for Nil exception because I don't have a top level PostSerializer defined.

[jejacks0n]

I was unable to determine best how to test this, because I would've expected an existing test to be failing. Give me some direction on that and I'll get it backfilled.

In addition to that, I may be pushing fixes here and there as we need them and am rolling with 0.10 as close to production ready. Can someone provide some clarity of what that timeline looks like so we can plan internally for this? Thanks!

[jejacks0n]

There was a follow up question about general structure of these options.. I'm wondering if using serializer: as an option for the associations makes perfect sense. In the controller if I have an array, there's the flexibility of using serializer: for the collection, or each_serializer: for each resource, defaulting to the ArraySerializer if otherwise unspecified.

It doesn't appear that the logic is symmetrical in regards to the associations -- if I wanted to use something that inherited from ArraySerializer for instance, it's not possible as it currently stands. Is this something that we think would add value/be merged?

[calebhearth]

@jejacks0n It appears that the specs are failing on Rails 4.0 because of a version conflict in Minitest. Was that change related to the options hash being passed in?

[calebhearth]

As far as tests, possibly something here? That's the only place in the test suite I see has_many mentioned.

[jejacks0n]

I'll be pushing a more comprehensive fix for this once I verify that I've resolved it for all cases.