Add tests for createRecord+unloadRecord

[Gabbyjose]

Added tests to cover creating and unloading an owner with associated pet, and creating and unloading a pet with associated owner

see #5472 for motivation

[hjdivad]

Under what circumstances do we have entries in _relationshipPromisesCache or _manyArrayCache but no record?

[runspired]

I suspect that should be an invalid state as of now but wouldn't necessarily be so in the future, moved back within the guard for hasRecord.

[hjdivad]

this comment can probably be one line

[runspired]

Cleaned up this comment a bit by moving a necessary clarifying bit from further up into the comment body.

[hjdivad]

What's the motivation for this?

[runspired]

Sync relationships act as client-side delete. Previously, in this case the manyArray would be cleared by the relationship in this scenario, but with the refactoring for RecordData the manyArray is now managed by InternalModel and thus InternalModel must clear it in this case.

[hjdivad]

Can you rephrase this? what's an example payload that illustrates this?

[runspired]

In the simplest setup, foo and bar have a 1:1 relationship.

Payload 1

{
  id: '1',
  type: 'foo',
  relationships: {
    bar: {
      data: { type: 'bar', id: '1' }
    }
  }
},
{
  id: '1',
  type: 'bar',
  relationships: {
    foo: {
      data: { type: 'foo', id: '1' }
    }
  }
}

After receiving payload one we have full knowledge of <foo:1>.bar and <bar:1>.foo.

Payload 2

{
  id: '1',
  type: 'bar',
  relationships: {
    bar: {
      data: { type: 'foo', id: '2' }
    }
  }
}

After receiving payload two, we have full knowledge of <bar:1>.foo and <foo:2>.bar. However, while we are aware that <foo:1>.bar is no longer <bar:1>, we do not know with certainty that the canonical state of the relationship is now null and not some other bar.

[hjdivad]

However, while we are aware that foo:1.bar is no longer bar:1, we do not know with certainty that the canonical state of the relationship is now null and not some other bar.

What does this have to do with the second payload? It is generally true that when the relationship of some other record changes this tells us nothing about any other relationship besides its inverse.

[hjdivad]

Put another way, once we sever the connection between <foo:1> and <bar:1> any other information about <bar:1>.foo tells us nothing about <foo:1>.bar unless the value is <foo:1>

Of course something might have changed on the server and our client state could be wrong, but that's always the case. The two flags being set represent client state; in the case you describe client state is still correct, no? Which flag do you think is not correct in this scenario?

[hjdivad]

is updating the state of unloaded records a new feature here or have we verified this was 2.12 behaviour?

[runspired]

confirmed, and this behavior is true through 3.3 stable: https://ember-twiddle.com/f022afd32f5c9d6769e66007a0004497?openFiles=templates.application.hbs%2C

[hjdivad]

ok seems fine although i presume we do not intend to make guarantees about the state of relationships on unloaded records and adding this here is solely a matter of pragmatism.

[igorT]

This is public api so we shouldn't change this