Included datas don't get injected nor used

[Tronix117]

Hey,

Could you take a look at this plunker : https://plnkr.co/edit/blGYD6Z7h05KCNN57fI7 (open the JS console)

We use the following format to also receive related models on an JSONApi API: CourseCompetency.findAll({include: 'category' }).

Otherwise despite the fact that it is correctly returned in the included key, the relationship seems to be dropped in the deserialization process by js-data-jsonapi. Expected behavior should be to inject it into the datastore.

Does I miss something ?

[BlairAllegroTech]

There are multiple problems here:

1. I'm not sure if it is valid to use the endpoint setting in the context of JsonApi. This is because JsonAapi uses a specific Url schema that maps types to Urls. This requires the JsonApi types to appear in resource Urls . See here http://jsonapi.org/format/#document-resource-identifier-objects

2. The Json data response you have here is returning the Child data in the main body with the parent as included data. The idea with HATEOAS is that you discover resources via links off of other resource. So here I would have presumed that you should request the parent object and include the child, not the other way around. My understanding of belongsTo within js-data is simply to allow bi-directional navigation of existing relationships. We have had other questions and confusion regarding this also.

3. There is also an issue with case sensitive names. This is something that I've been thinking about. In all of my tests i have used lower case type names and then made case insensitive comparisons on the resource Urls. This was so that Urls did not have to be strictly lower case. However when you introduce js-data type names with upper characters this no longer works. I think i should change this so that we perform case sensitive comparison, e.g. when searching for js-data relationships and fall back to case insensitive if not found, and possibly allow this behavior to be turned off also.

4. If I'm not mistaken js-data relationship configuration is just a java object, so relationship types are not strings:

relations: {
    belongsTo: {
      'CourseCategory': {
        localField: 'category',
        localKey: 'categoryId'
      }
    }
  }

Should be

relations: {
    belongsTo: {
      CourseCategory: {
        localField: 'category',
        localKey: 'categoryId'
      }
    }
  }

[Tronix117]

Thank you for your answer, and amazing job you made :)

1. I may be wrong here, but they actually make the distinction between the URL and the Type, I couldn't find any recommandation about using types as endpoints. I guess it's valid and make sense sometime to use different writings for URL and types, as soon as it is consistent.

2. I guess it should work anyway, sometime you get all the childs and you want to get back each parents to show their name. Simple exemple: you have your Users and each user is associated to a Role, you may not retrieve all Roles in order to retrieve Users, but you better retrieve all Users and the corresponding Roles.

3. I did a debugging session, and that is what I found. When you look at JSONApi specifications, they insist on having Case-Sensitive comparison for almost everything and especially Types. I tried to remove those toLowerCase checks, but it seems it's a bit more complicated and I didn't have the time to carry on my investigations.

4. What you wrote and what I wrote are exactly the same thing, for Javascript, you may or may not provide the quotes on keys when declaring object using JSON representation, the engine will still infer them anyway. I could have wrote that: {"relations": { 'belongsTo': {CourseCategory: {}}}. You have to use quotes when you do not use safe characters or start the key by a number, however when it's a simple string you can omit it.

Anyway I think the number 3 is a must-have !

[BlairAllegroTech]

Yip, I'm actually a bit rusty I've been doing a lot of .NET development recently and have not been maintaining this project.

I'll add an issue for 3. I'm trying to remember if there was another reason for using the lower case comparison. I'll do some digging around.

I think for 1 you are correct, but unfortunately there is one case where i had to use the self link to get the parent id, see here : https://github.com/BlairAllegroTech/js-data-jsonapi/blob/js-data-jsonapi/src/JsonApiSerializer.ts#L1372

This may not be strictly correct, but there are cases where there is no other way of doing this... E..g JsonApi doesn't really have a concept of parent

[BlairAllegroTech]

@Tronix117 Please take a look at these updates, i'd like to close this one..

[Tronix117]

Hey, I took a look at your modifications, it works better, I didn't tests all use cases, but it did the work except for the belongsTo with include issue (still doesn't work).

Also I took a look at your code, and I don't think you should base yourself on the endpoints, endpoints should only be used to retrieve datas, not to infer parent-id for exemple. If parent id is relevant it should be included in the response within relationships object.

I started to implement the belongsTo with include