IDs on relationships for new records are serialized as null

[cristinawithout]

When you create a new record (Record B) and set its relationship to another record (on Record A), saving the existing record (Record A) without first saving the new record (Record B) serializes the relationship to the new record with ID null.

{ "data": { //... "relationships": { "relB": { "data" : { "type": "modelB", "id": null } } } } }

Demo:
https://ember-twiddle.com/a27a8e9da784895c266ddd3e0b39bb1f?openFiles=templates.application.hbs%2C

My recommendation is that an object in a relationship with ID null should be excluded during serialization. Otherwise, you're leaving it up to your server (for which you may not control the code) to figure out how to handle these null IDs. If the server doesn't know and saves the null relationship, next time you request data for the record from the server, you have an invalid relationship with a null ID.

The issue of null IDs was also reported in #3953, but attached to the request to serialize attributes instead. That issue was closed because the JSON API spec does not support relationship attributes, but the underlying issue of null IDs went unaddressed.

[mixonic]

@cristinawithout When you remove a relationship, the server must be passed that removal somehow. I expect the two systems (sending an empty initial relationship and sending an empty relationship that had content) are related.

null as an id just represents "there is nothing at this relationship", yes?

[cristinawithout]

No. It's not when removing a relationship that a null ID is being serialized. It's when you add a newly created recordA to a relationship on recordB. Then when saving recordB before saving recordA, you get id null for recordA.

Also a removal is not done via a null id. Per the JSON API spec, it's done by removing the object, which in a belongsTo relationship serializes to null (not an object with ID null) and on a hasMany serializes to an array with only the remaining items in the relationship or an empty array (if there are no other remaining items).

Null IDs in a relationship are not covered in the spec, which leaves whoever is implementing the server to guess at what Ember Data's current implementation intends when it sends them.

A shorter example than the twiddle:

// modelA
export default Model.extend({
   belongsToRel: DS.belongsTo('modelB')
})

// modelB
export default Model.extend({
   inverseBelongsToRel: DS.belongsTo('modelA')
})

var modelA = store.findRecord('modelA', '1');
var modelB = store.createRecord('modelB', { ... });
modelA.set('belongsToRel', modelB);
modelA.save();

modelA is serialized to:

{ "data": { ... "relationships": { "belongsToRel": { "data" : { "type": "modelB", "id": null } } } } }

It should serialize to:

{ "data": { ... "relationships": { "belongsToRel": { "data" : null } } } }

because otherwise the server will have to guess at what {"data": { "type": "modelB", "id": null } } is supposed to represent (was a record deleted? it is supposed to create an empty record with null id? is it supposed to just ignore it? is it supposed to treat it like { "data" : null } which is defined in the spec and remove any existing records from that relationship?)

Then when modelB is saved, it will include the serialized modelA relationship - or if the relationship is a hasMany that's not configured to be serialized on modelB, the relationship could be persisted to the server by saving modelA again after modelB has saved (unlikely that you'd want to save modelA twice, but you shouldn't be prevented doing things in any order you choose because a new record in a relationship is serialized into what's essentially junk).

[pangratz]

Thanks @cristinawithout for this excellent bug report! The twiddle you provided made it immediately clear what the issue is!

[samselikoff]

I ran into this as well, and reached out to @dgeb. Indeed a payload that looks like

{
  data: {
    type: 'books',
    id: '1',
    relationships: {
      author: {
        data: {
          type: 'authors',
          id: null
        }
      }
    }
  }
}

is invalid JSON:API. The data key here should either be nullor perhaps even the author key should be non-present.

[runspired]

This was resolved in #5317 and #5324