store.unloadAll sets async belongsTo relationships to null #4996
Comments
|
Also tracking in #4986. |
stefanpenner
added a commit
that referenced
this issue
Jul 25, 2017
…rd() For an async relationship [x, y] with x.unloadRecord(), now adjusts only the relationship’s currentState, leaving that relationship’s canonical state alone, ensuring the existing client-side delete semantics are preserved. But when that relationship is reloaded, the canonicalState consulted. For sync relationship [x, y] with x.unloadRecord(), both currentState and canonical state are updated. This is to mirror the client-side delete semantics. But since we cannot reload a sync relationship we must assume this to be the new canonical state and rely on subsequent `push` or `adapterPayloads` or manual `store.push` to update. This aims to: * [FIX] hasMany arrays never contain dematerialized records (so they no longer become broken) * [FIX] using unloadRecord as a type of client side delete is restored * [PRESERVE] the garbage collector pass to cleanup orphaned models * [PRESERVE] second access to a relationship which did contain an unloadRecord to cause a reload note: if both sides of a relationships are unloaded, the above doesn’t apply. This is largely just when members of a loaded relationship are themselves unloaded. [fixes #4986 #5052 #4987 #4996]
stefanpenner
added a commit
that referenced
this issue
Jul 25, 2017
…rd() For an async relationship [x, y] with x.unloadRecord(), now adjusts only the relationship’s currentState, leaving that relationship’s canonical state alone, ensuring the existing client-side delete semantics are preserved. But when that relationship is reloaded, the canonicalState consulted. For sync relationship [x, y] with x.unloadRecord(), both currentState and canonical state are updated. This is to mirror the client-side delete semantics. But since we cannot reload a sync relationship we must assume this to be the new canonical state and rely on subsequent `push` or `adapterPayloads` or manual `store.push` to update. This aims to: * [FIX] hasMany arrays never contain dematerialized records (so they no longer become broken) * [FIX] using unloadRecord as a type of client side delete is restored * [PRESERVE] the garbage collector pass to cleanup orphaned models * [PRESERVE] second access to a relationship which did contain an unloadRecord to cause a reload note: if both sides of a relationships are unloaded, the above doesn’t apply. This is largely just when members of a loaded relationship are themselves unloaded. [fixes #4986 #5052 #4987 #4996]
stefanpenner
added a commit
that referenced
this issue
Jul 25, 2017
…rd() For an async relationship [x, y] with x.unloadRecord(), now adjusts only the relationship’s currentState, leaving that relationship’s canonical state alone, ensuring the existing client-side delete semantics are preserved. But when that relationship is reloaded, the canonicalState consulted. For sync relationship [x, y] with x.unloadRecord(), both currentState and canonical state are updated. This is to mirror the client-side delete semantics. But since we cannot reload a sync relationship we must assume this to be the new canonical state and rely on subsequent `push` or `adapterPayloads` or manual `store.push` to update. This aims to: * [FIX] hasMany arrays never contain dematerialized records (so they no longer become broken) * [FIX] using unloadRecord as a type of client side delete is restored * [PRESERVE] the garbage collector pass to cleanup orphaned models * [PRESERVE] second access to a relationship which did contain an unloadRecord to cause a reload note: if both sides of a relationships are unloaded, the above doesn’t apply. This is largely just when members of a loaded relationship are themselves unloaded. [fixes #4986 #5052 #4987 #4996]
stefanpenner
added a commit
that referenced
this issue
Jul 25, 2017
…rd() For an async relationship [x, y] with x.unloadRecord(), now adjusts only the relationship’s currentState, leaving that relationship’s canonical state alone, ensuring the existing client-side delete semantics are preserved. But when that relationship is reloaded, the canonicalState consulted. For sync relationship [x, y] with x.unloadRecord(), both currentState and canonical state are updated. This is to mirror the client-side delete semantics. But since we cannot reload a sync relationship we must assume this to be the new canonical state and rely on subsequent `push` or `adapterPayloads` or manual `store.push` to update. This aims to: * [FIX] hasMany arrays never contain dematerialized records (so they no longer become broken) * [FIX] using unloadRecord as a type of client side delete is restored * [PRESERVE] the garbage collector pass to cleanup orphaned models * [PRESERVE] second access to a relationship which did contain an unloadRecord to cause a reload note: if both sides of a relationships are unloaded, the above doesn’t apply. This is largely just when members of a loaded relationship are themselves unloaded. [fixes #4986 #5052 #4987 #4996]
stefanpenner
added a commit
that referenced
this issue
Jul 25, 2017
…rd() For an async relationship [x, y] with x.unloadRecord(), now adjusts only the relationship’s currentState, leaving that relationship’s canonical state alone, ensuring the existing client-side delete semantics are preserved. But when that relationship is reloaded, the canonicalState consulted. For sync relationship [x, y] with x.unloadRecord(), both currentState and canonical state are updated. This is to mirror the client-side delete semantics. But since we cannot reload a sync relationship we must assume this to be the new canonical state and rely on subsequent `push` or `adapterPayloads` or manual `store.push` to update. This aims to: * [FIX] hasMany arrays never contain dematerialized records (so they no longer become broken) * [FIX] using unloadRecord as a type of client side delete is restored * [PRESERVE] the garbage collector pass to cleanup orphaned models * [PRESERVE] second access to a relationship which did contain an unloadRecord to cause a reload note: if both sides of a relationships are unloaded, the above doesn’t apply. This is largely just when members of a loaded relationship are themselves unloaded. [fixes #4986 #5052 #4987 #4996]
stefanpenner
added a commit
that referenced
this issue
Jul 25, 2017
…rd() For an async relationship [x, y] with x.unloadRecord(), now adjusts only the relationship’s currentState, leaving that relationship’s canonical state alone, ensuring the existing client-side delete semantics are preserved. But when that relationship is reloaded, the canonicalState consulted. For sync relationship [x, y] with x.unloadRecord(), both currentState and canonical state are updated. This is to mirror the client-side delete semantics. But since we cannot reload a sync relationship we must assume this to be the new canonical state and rely on subsequent `push` or `adapterPayloads` or manual `store.push` to update. This aims to: * [FIX] hasMany arrays never contain dematerialized records (so they no longer become broken) * [FIX] using unloadRecord as a type of client side delete is restored * [PRESERVE] the garbage collector pass to cleanup orphaned models * [PRESERVE] second access to a relationship which did contain an unloadRecord to cause a reload note: if both sides of a relationships are unloaded, the above doesn’t apply. This is largely just when members of a loaded relationship are themselves unloaded. [fixes #4986 #5052 #4987 #4996]
stefanpenner
added a commit
that referenced
this issue
Jul 25, 2017
…rd() For an async relationship [x, y] with x.unloadRecord(), now adjusts only the relationship’s currentState, leaving that relationship’s canonical state alone, ensuring the existing client-side delete semantics are preserved. But when that relationship is reloaded, the canonicalState consulted. For sync relationship [x, y] with x.unloadRecord(), both currentState and canonical state are updated. This is to mirror the client-side delete semantics. But since we cannot reload a sync relationship we must assume this to be the new canonical state and rely on subsequent `push` or `adapterPayloads` or manual `store.push` to update. This aims to: * [FIX] hasMany arrays never contain dematerialized records (so they no longer become broken) * [FIX] using unloadRecord as a type of client side delete is restored * [PRESERVE] the garbage collector pass to cleanup orphaned models * [PRESERVE] second access to a relationship which did contain an unloadRecord to cause a reload note: if both sides of a relationships are unloaded, the above doesn’t apply. This is largely just when members of a loaded relationship are themselves unloaded. [fixes #4986 #5052 #4987 #4996]
stefanpenner
added a commit
that referenced
this issue
Jul 25, 2017
…rd() For an async relationship [x, y] with x.unloadRecord(), now adjusts only the relationship’s currentState, leaving that relationship’s canonical state alone, ensuring the existing client-side delete semantics are preserved. But when that relationship is reloaded, the canonicalState consulted. For sync relationship [x, y] with x.unloadRecord(), both currentState and canonical state are updated. This is to mirror the client-side delete semantics. But since we cannot reload a sync relationship we must assume this to be the new canonical state and rely on subsequent `push` or `adapterPayloads` or manual `store.push` to update. This aims to: * [FIX] hasMany arrays never contain dematerialized records (so they no longer become broken) * [FIX] using unloadRecord as a type of client side delete is restored * [PRESERVE] the garbage collector pass to cleanup orphaned models * [PRESERVE] second access to a relationship which did contain an unloadRecord to cause a reload note: if both sides of a relationships are unloaded, the above doesn’t apply. This is largely just when members of a loaded relationship are themselves unloaded. [fixes #4986 #5052 #4987 #4996]
|
I believe we can close this now due to the fix @stefanpenner. If this is still an issue on latest master please reopen or submit a PR with a failing test :D |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reproduced on [email protected] & 2.13.0
When applying:
store.unloadAll('some-model')all loaded records which has an async
belongsTo('some-model')will get null as a value for that relationship.Here is a reproduction: https://ember-twiddle.com/b116abf73fdf50a7bf706f2062c1efcd
Note: When viewing the twiddle app files, ignore the
adapters/application.js. I used the adapter implementation of https://github.com/emberjs/ember-data-fixture-adapter just to have fixedDS.Models in the twiddle app.The text was updated successfully, but these errors were encountered: