Add docs for `include` in Json adapter.

[beauby]

The include option with Json adapter works the same as with the JsonApi adapter, but it's not written anywhere in the docs.

[vasilakisfil]

That's interesting! Do you know if fields or something relevant is also working with JSON adapter? If not is there any interest to send a pull request for that ? Cause I really need it and I am going to implement it anyway..

[beauby]

@vasilakisfil Currently you can use the fields option with Json/Attributes adapters, but you can only filter the primary resources (render json: @posts, fields: 'id, title, body').

[beauby]

I am not sure extending the Json adapter to fit the broader JSON API style fields option (where you specify the attributes for each type) is a good thing. The goal is to keep Json/Attributes adapters very simple.

[vasilakisfil]

given that's an adapter I don't think it's an issue. Plus there should be
an adapter that opts for compatibility with 0.9.x and 0.8.x (supporting
only, except etc options). Otherwise the way to go is create an external
plugin adapter just like ember? is there support for that?
On Oct 6, 2015 5:03 PM, "Lucas Hosseini" notifications@github.com wrote:

I am not sure extending the Json adapter to fit the broader JSON API style
fields option (where you specify the attributes for each type) is a good
thing. The goal is to keep Json/Attributes adapters very simple.

—
Reply to this email directly or view it on GitHub
#1243 (comment)
.

[beauby]

Oh yeah, AMS is deisgned in such a way that you can create your own adapter and/or extend an existing one. I agree the migration from 0.8/0.9 should be made as easy as possible, I'm just not sure what's the best way to make that happen.

[NullVoxPopuli]

maybe for the initial 0.10 release, we could copy the old adapters? maybe name them json_08, json_09 etc

[NullVoxPopuli]

and then in the next release after 0.10, remove them?

[beauby]

First we have to make sure it is actually possible to build such legacy adapters.

[phcoliveira]

@beauby, is there any reason to use the option include when rendering an object? My point is, if that option must be included when of rendering - render json: @posts, include: 'comments' e.g. -, I expect the serializer to exclude the comments relationship when used without the include option.

I have a use case where a user can have many sessions, in order to be able to sign them all out in case something bad happens. I have something like this:

class SessionsController
# ...
render json: @session, include: 'user'
# ...
end

class SessionSerializer
# ...

# I am not asking for the "UserSerializer" to include the "sessions" relationship.
# Nevertheless, it does. The "UserSerializer", for its own logical reasons, also
# declares its own relationship with "sessions" and other models.
# I should explicitly use the "include" option here if I wanted the other relationships
# to be included.
has_one :user, serializer: UserSerializer # include: ['other', 'relationships']
# ...
end

In my use case, I don't want the relationships of the user model to be included, but they do.

[beauby]

@phcoliveira Could you open a separate issue with the definition of your serializers and your render calls and a description of the unexpected behavior?