Ember-data - relationships not getting loaded

Ember Data
1

I’m encountering an issue with Ember Data (version 5.3.0) involving relationships not resolving as expected. My setup:

  • TPE model has a belongsTo relationship with the network-construct (NC) model:

js

networkConstruct: belongsTo('network-construct', {
  async: false,
  inverse: null
}),
  • The NC data is fetched and preloaded before TPE is loaded (the NC API is called first), then much later, the TPE API call is made. I expect that:

js

get(tpe, 'networkConstruct.id')

should return the network construct’s ID.

  • The TPE API response includes:

json

"networkConstruct": {
  "data": {
    "type": "networkConstructs",
    "id": "1b4543e5-d142-33f8-8385-3c6b9285ae9c"
  }
}
  • I have two backend systems: one with Cassandra and one with Postgres. Both produce identical JSON API responses.

Problem: When using the Postgres backend, the relationship is not resolved and ncID is always null, even though it works fine with Cassandra. There are no apparent differences in the JSON.

Additional context:

  • Ember Data version: 5.3.0
  • Both models are defined as described above.
  • ncID is null when accessed.

Questions:

  • Has anyone encountered a similar issue with relationships not resolving (especially with multiple backends)?
  • Are there any additional diagnostics or common gotchas for relationship resolution with Ember Data 5.x I should check?
  • Suggestions, debugging strategies, or pointers to relevant documentation would be much appreciated!
2

This part doesn’t seem right to me. If:

  • the response JSON is literally exactly the same
  • the models are exactly the same
  • the serializers/adapters are exactly the same

Then Ember should see them as exactly the same. There must be some difference in one of those pieces…

If I were debugging this I guess I’d try a few things:

  • really carefully compare the JSON responses, the models, and the serializers between the PG/Cassandra versions. Something doesn’t add up there.
  • use the low level API: tpe.belongsTo('networkConstruct').id() to make sure there’s nothing there, also inspect some of the other stuff on the ref like remoteType to make sure it all looks right
  • play around with the “relationship config” e.g. make it an async relationship and see what happens, add an inverse and see if that behaves any differently, etc.
  • peek the store and make sure all the records you expect are there and look correct and the problem is they just aren’t being linked properly
1 Like
3

Activating the logging is probably the best bet here, it uses structuredClone to clone the payload at insertion time for logging, so zero mutation guarantee. For 5.3+

setWarpDriveLogging({ LOG_PAYLOADS: true, LOG_CACHE: true });

See debugging | WarpDrive

1 Like