Confused about RelData

[teleclimber]

Document has a field called RelData, which is described as "Relationships where data has to be included in payload". RelData does not get set anywhere, and it appears that it is the job of the handler to set it.

However if the url specifies a "include" in the query parameters it seems RelData should be fully determined by that.

In URL.Param there is a RelData field too, but it never gets set, even if I have a url that specifies an `?include=...".

Can you explain this? Thanks.

Second question: if I do set Doc.RelData manually in my handler how do I get he document to include second-level resources, like "/articles?include=comments.author".

For normal relationships I can do:

Doc.RelData = map[string][]string{
   "articles": {"comments"}
}

But I can't figure out how to include "comments.author". A quick look at the code indicates this is not supported? Or am I missing something?

Thanks.

[mfcochauxlaberge]

Doc.RelData = map[string][]string{
   "articles": {"comments"},
}

In this example, all resources of type articles will include data under the comments relationship.

You might want to include extra resources under the included field. That can be done, but you need to ensure that you do set RelData properly in order to have proper linkage. The library won't verify that for you. There is an exception where you can include resources even though their IDs don't appear under any relationship, and that's when you hide some fields through the fields parameters.

I also can't make include fully decide what RelData is because you might one to include relationship data but not the resources themselves. Sometimes the IDs are only what you want.

Maybe the library could verify the integrity by making sure RelData is enough to comply with include. It might be a useful feature. For now, RelData is a different concept than include.

To answer you second question, you would need to add "users": {"rel1", "rel2"} (assuming an author is a user). That means you decide what the relationships are based on the type, not their position in the relationship tree. That is a design decision I made, which could be modified if there's evidence that a different approach is better.

Using the relationship tree for RelData is tricky. Let's say you want to retrieves one user, and would like to include all the articles written by that user and all the comments under those articles. You also want to include comments liked by that user. In RelData, you might specify different relationships for liked_comments and articles.comments. But if a user likes a comment that was written under one of their articles, that comment would still appear once under the included field. So which RelData setting would you use? Maybe a merge of both could be a reasonable approach! But that involves a bit of magic under the hood.

So that's how it currently works. It works and it's not broken, but there is room for improvement.

Let me know if that answers your questions. I'm open to ideas. I'll keep this open for now to remind myself to think about this issue.

[teleclimber]

Thanks for the explanation. It seems JSON:API has more quirks than I expected. I appreciate your work. Feel free to close when you wish.