Include option for associations in serializers

[oyeanuj]

I am migrating from 0.9.3 to 0.10.0-rc3 to take advantage of json-api. Based on the current docs, it seems if I want the association's data as part of the response, I will have to specify it as part of 'include' option when calling render in the controller.

Is there a way to specify this in the serializer instead of the controller, so that I can specify it once and everytime I render that serializer, those associations are included in the json-api by default (instead of having to specify it every time I render that object)? That seemed to be the default behavior in the 0.9.x

TLDR: Instead of

# posts_controller.rb
render @post, include: ['author', 'metrics', 'media']

something like this:

# post_serializer.rb

has_many :metrics #or included by default which would be ideal
has_many :media, only: [title]
has_many :publishers, except: [publisher_bio]

# or even
has_one :author, include: true 

Maybe it is already there and I missed it. Either way, I would love some clarity.

Thanks!

[beauby]

Not at the moment, but there is discussion about it.

[oyeanuj]

Thanks for the quick response!

Fwiw, I think having them included by default would make the upgrade path from 0.8 and 0.9 to 0.10 much easier and more backwards compatible (and not needing to include associations every time or refactor code to prevent repetition).

[iMacTia]

@oyeanuj, PR #1127 does exactly what you're asking, but unfortunately have been merged the 21st of September, only 5 days after 0.10.0-rc3 was released.
@joaomdmoura, any plan for the rc4? this feature have been requested by many and rc3 have been out for almost 2 months now.

[oyeanuj]

@iMacTia Thats really good to know, thank you for that. Couple of questions with your PR:

1. Without the include, does it only get the type and id? And include specific fields if we want more of that object? Ideally to maintain backward compatibility, there would be an include: false option which only then shows the id & type but by default associations would be included.
2. Does your PR also support except and only options on associations too for backwards compatibility?

@joaomdmoura If I can add to the rc4 question :) - when is the 0.10 final release roughly aimed for?

Thanks again!

[iMacTia]

@oyeanuj unfortunately I can't take the merit for that PR because is all @NullVoxPopuli work :)
So it's quite hard for me to correctly answer your question, also because I've never used the json-api adapter so far, but only the standard json one.
I'm simply really interested as much as you are on getting this new features out od the door ;) So sometimes I open the project page to see what's the status.

[beauby]

@oyeanuj

1. Have a look at the JSON API spec. The idea is that it differentiates between "resources" (actual objects) and "resource identifiers" (only type and id, which are basically references to other resources). When a resource is referenced as a relationship for an other resource, only its resource identifier appears. Using include, you can have the actual resource in the included part of the JSON document.
2. No except / only for now, although it is being discussed.

[oyeanuj]

@beauby Thanks for the context, I was missing that.

In that case, it would be really helpful to have include',except,only` options in the serializer when specifying associations. That would make the upgrading process much easier wherein folks don't have to rework everyplace where they are currently using those options in the 0.8 and 0.9 versions.

Thanks again for your work on this library!

[beauby]

I'll try to issue a PR that adds support for only/except on associations tonight, we'll see whether it gets traction!

[oyeanuj]

@beauby thank you, appreciate it!

[bf4]

@beauby

I'll try to issue a PR that adds support for only/except on associations tonight, we'll see whether it gets traction!

For JSON API, there shouldn't be a need for only exclude, since it's always opt-in. Otherwise, it would be an argument to the include tree thingy, right?

[oyeanuj]

@bf4 Having the only/except also is allowing for major backwards compatibility for those upgrading from 0.8.x and 0.9.x. When dealing with associations in serializers, only and except turn out to be invaluable to customize API responses.

[bf4]

You're right. I keep mixing up internal vs external options. Internal like here would work well with serilization scopes and requested attributes

B mobile phone

On Dec 8, 2015, at 10:52 PM, oyeanuj notifications@github.com wrote:

@bf4 Having the only/except also is allowing for major backwards compatibility for those upgrading from 0.8.x and 0.9.x. When dealing with associations in serializers, only and except turn out to be invaluable to customize API responses.

—
Reply to this email directly or view it on GitHub.

[beauby]

@bf4 There will be some discussion about priorities of the options, but my current thought is "if an explicit include option is provided to the render call, disregard the serializer-level options".

[bf4]

Agreed

B mobile phone

On Dec 9, 2015, at 6:16 AM, Lucas Hosseini notifications@github.com wrote:

@bf4 There will be some discussion about priorities of the options, but my current thought is "if an explicit include option is provided to the render call, disregard the serializer-level options".

—
Reply to this email directly or view it on GitHub.