-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pivot (join) table attributes not included in response #17
Comments
Should they be added like |
I'd imagine they'd be rendered as a standard relationship. As an example, if you had an |
I was imagining it like if you're returning as the main the |
I think someone did mention about using Given it's not explicitly defined in the spec, I believe we need to see how front-ends are consuming it before we implement. Are you running into this issue specifically? |
No, I was just curious. You're right, not worth implementing yet. |
@chamini2 FYI I came across a case for this in my application. Essentially, I need to utilize some of the additional data in a join/pivot table in my application. It appears the suggested way to do this is through the use of a For example, in my application, I have an When requesting an {
"data": {
"type": "appointment",
"attributes": {
"startsAt": "2016-03-09T12:00",
"endsAt": "2016-03-09T12:30",
"businessNotes": "Be careful -- Critter likes to try and get out the door when it's opened.",
"customerNotes": "Critter has been having the shits. Keep an eye on him."
},
"relationships": {
"pets": {
"data": [{
"type": "pet",
"id": 1
}]
},
"services": {
"data": [{
"type": "service",
"id": 1
}],
"meta": {
"specificPets": [1, 2]
}
}
}
}
} Ember Data (allegedly one of the first implementations of consuming JSON API) supports this out of the box. For reference, here's their documentation: https://guides.emberjs.com/v2.8.0/models/handling-metadata/ My proposal is that we serialize |
We have the same case (obviously not for pets) and handled it with a meta too. The thing is that we didn't include it in the A question, shouldn't it be:
|
I thought that too at first, but it actually sits one level up: http://jsonapi.org/format/#document-resource-object-relationships |
And what if you had a |
It would just be another |
But what would the |
Ah, sorry. I see what you're saying. Good question! |
Maybe the |
Related: SeyZ/jsonapi-serializer#78 |
As that thread mentioned, it could be done by adding everything needed to the |
Not sure that it would be compliant w/ the spec. |
Yeah, I did see that. The only reason I wouldn't go that route is because Ember Data follows the spec's recommendations. That said, in order to use it the other way, I'd have to submit a PR to Ember Data and not sure it's worth the effort :) |
The cleaner way I see is adding it in the |
Can you give an example?
This isn't ideal for my case. I selectively |
{
"data": {
"type": "appointment",
"attributes": {
// info
},
"relationships": {
"services": {
"data": [{ "type": "service", "id": 1}, { "type": "service", "id": 2}]
}
}
},
"included" : [
{
"type": "service",
"id": 1,
"meta": {
"specificPets": [1,2]
},
"attributes": {
...
}
},
{
"type": "service",
"id": 2,
"meta": {
"specificPets": [2,3]
},
"attributes": {
...
}
}
]
} |
Certainly possible, but I don't like that we'd be forcing the inclusion of relationships in order to make this work. Are you opposed to following the spec as-is for the time being with the option to add more meta functionality down the road? |
You propose to leave this as is for now and consider it later or to implement it somehow? |
No, I'm proposing that we add the |
Then sure!, if it's compliant I'm in. |
When utilizing a
belongsToMany
relationship in Bookshelf, the_pivot
fields are not being included in the response.The text was updated successfully, but these errors were encountered: