Relations do not appear to work without "cacheResponse: true" on Node.js

[techniq]

So I've spent the good part of this evening trying to get familiar with js-data within my backend (Node.js) and how it handles relations. After a few problems on my side (I had 2 belongsTo objects under relations for defineResource to name one), I think I've stumbled across an issue:

Until I set cacheResponse: true in JSData.DS's configuration I am unable to get any of my relation properties (belongsTo / hasMany) to be populated. I tried populating using

...
const Race = store.defineResource({
  name: 'race',
  relations: {
    belongsTo: {
      address: {
        localField: 'address',
        localKey: 'address_id'
      }
    },
  }
});

const Address = store.defineResource({
  name: 'address',
  relations: {
    hasMany: {
      race: {
        localField: 'races',
        foreignKey: 'address_id'
      }
    }
  }
});
...

let address = yield new store.Address.create(fixtures.address.race1);
let raceData = fixtures.race.race1;
raceData.address_id = address.id;
let race = yield new store.Race.create(raceData);
expect(race.address).to.exist; // AssertionError

let race2 = yield store.Race.loadRelations(race, ['address']);
expect(race2.address).to.exist; // AssertionError

If I set cacheResponse: true, the assertions succeed. Due to the issues explained on JSData on the Server, it seems like enabling cacheResponse: true would not be advisable.

On a semi-related note, the docs under Configuration do not indicate some defaults being different when ran under Node (like the "JSData on the Server" page does). It would be helpful if this documentation indicated the different default values based on the environment. I also wasn't sure if items like findHasMany, findBelongsTo, etc were set to false by default on Node, or if this was just recommended per the docs.

[jmdobry]

It's not very well documented, but the relations getters only work when the relations are in the store. When cacheResponse is false, then you also can set linkRelations false, and the relation getters won't be created, and your data will have references to the plain relation objects.

If you have suggestions for changes to the docs, I'd be happy to see them. You can click the "Suggest Edits" button and I can merge your changes in. Where did you find findHasMany, findBelongsTo, etc.? Those options have been removed from JSData 2.x.

[techniq]

I found the findBelongsTo/etc mention in the docs under the Configuration api docs as well as under the JSData on the Server guide.

For linkRelations, I assume the localField is the name of the property when linkRelations is set? Is this field required to get the linked relationship, or will the relations object key be used by default? For example, if I omit localField, will race still get an address property?

const Race = store.defineResource({
  name: 'race',
  relations: {
    belongsTo: {
      address: {
        localField: 'address',
        localKey: 'address_id'
      }
    },
  }
});

Same for localKey, is this a required field or is there some convention that will be the fallback if not set?
Could it be made as simple as:

relations: {
    belongsTo: {
      address: {}
    }

As for cacheResponse: false / Node.js, it seems like I will definitely need cacheResponse: true enabled but call store.clear() to purge the local cache. By clearing the cache each API request (for my koa backend), it will allow the relationships to be built but not grow unnecessarily large over time. I'll still keep bypassCache: true so all queries always pull fresh from the SQL server.

It might be helpful to give the store a temporary cache the end user can regulate themselves. For example, having a dependency injected setup where a per-request cache is injected and given to the store to use. For now, calling clear() on the cache I think will work for my use case.

[jmdobry]

Even if you're setting linkRelations to false, you still define the relations like you normally would.

[techniq]

@jmdobry I came across a different issue today (that ultimately is related here, so hold tight :) ).

If I called Foo.find(1) and then later called Foo.find(1, { with: 'bars' }) I would not get the bars property populated as it would pull the instance from the cache. I had intermittent success using bypassCache: true but still needed to purge the queue between API requests, as otherwise the requests not wanting bars populated would still get it since they were in the cache (as I still need cacheResponse: true to populate the hasMany/etc properties.

While looking at the js-data-sql source, I noticed the tests were using the js-data-sql adapter directly yet still getting the belongsTo / hasMany properties populated. I decided to start using the sql adapter directly and this appears to be work around this issue: have relations populated on my backend but without the bad effects of a shared cache between API requests.

Does using the adapter directly have any downsides or is there a better approach to this. I'm not overly fond of using adapter.find(models.Race, this.params.id, options) over models.Race.find(this.params.id, options) but I can live it to have the issue resolved.

[techniq]

This is fixed with js-data 2.4 that defaults linkRelations: false in Node