Including relations of relations requires include to be listed twice.

[sonthonaxrk]

http://jsonapi.org/format/#fetching-includes

In order to request resources related to other resources, a dot-separated path for each relationship name can be specified:

---

Currently a request like this will fail to include anything.

/articles/1?include=comments.author

However it will work if I include comments and comments.author.

/articles/1?include=comments,comments.author

[jerel]

I had noticed this quirk also. Do you feel like it's a bug or a feature. I'm not sure that including comments.author without comments makes sense.

[sonthonaxrk]

From the spec:

Because compound documents require full linkage, intermediate resources in a multi-part path must be returned along with the leaf nodes

I think it's a bug. The JSON API spec asks for intermediate resources to be returned. Right now DRF-JSON API doesn't return anything.

[jerel]

Ah yes. It does spell it out there in the spec.

[sonthonaxrk]

I'm happy to fix this myself over the weekend.

[jsenecal]

It's not a bug, but rather a missing feature IMO... Including comments.author is very different from including comments-author and including comments.author without including comments would be silly...

The cited specs is talking about the comment-author I think...

[sonthonaxrk]

@jsenecal are you sure including comments.author is different from comments,comments.author? Other than the latter being redundant?

[jsenecal]

Yes, well, I do understand the redundancy.

The example we have here might not be the best one.

Let's use comments.tags...
Not all comments have tags. Including all comments when we really are in fact interested in tags is wasted machine time.

[jsenecal]

Although, reading the spec referenced by #149 (comment) it appears that it is actually the other way around and that including comments.author should include all comments as well. Sorry for the confusion/back and forth.

comments-tags would be for when one wants all the tags with the least amount of comments possible.

Feel free to work on this but be warned that it's a feature easy to break as the tests in place are not covering all the possible use cases (like relations to self).

[sonthonaxrk]

Talking of tests some of the utils.py methods don't have any, before I write a fix, I'd like to make some headway on that.

Some of the functions are quite long and might be more testable if broken up.

[jerel]

The tests for utils.py are here https://github.com/django-json-api/django-rest-framework-json-api/blob/develop/example/tests/unit/test_utils.py

[jsenecal]

@rollokb any success on implementing broken tests ?