You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a model record that has async hasMany relationships is saved while the hasMany relationship property has yet to be fulfilled by the promise object, the serializer produces an empty array which results in incorrect representation of the relationship to be informed to the backend.
The offending logic appears to be that the promise object which implicitly has ID references to the eventual records that will be retrieved to fulfill the relationship simply returns an empty array when the property record (the PromiseArray object) returns mapBy('id') before those resolutions have been loaded.
This is problematic for representing the relationship state of the model being saved since whether the model eventually resolved those hasMany relationships or not for use should not inform an update operation for the model record where the relationship mapping for affected hasMany property gets reset to empty.
In order to work-around this issue, I've used the below snipped as a hack by extending the RESTSerializer and having the serializer skip the unfulfilled hasMany relationships and not including it in the resulting PUT operation.
The above hack only works if the server-side backend can properly deal with PUT operations where specific properties are not included in the JSON payload.
I'm thinking the proper fix would be to directly alter the PromiseArray used in the context of hasMany to always return all of the IDs (whether fulfilled or not by the given model) when mapBy('id') is called on it so that it does not improperly inform state about the hasMany property being empty. I've dug a little and it seems that this particular scenario may require a bit of creativity since technically there are no explicit records to iterate in a forEach to apply the mapping to extract out the array of record IDs... yet.
I've encountered this issue in ember-data 1.0.0-beta.8 but upon brief scan through latest code it looks like it may still be affecting current snapshots.
Your comments/feedback will be welcome for proper workaround as necessary in this scenario. If current behavior is actually the expected behavior, would like rationale on that as well.
The text was updated successfully, but these errors were encountered:
When a model record that has async hasMany relationships is saved while the hasMany relationship property has yet to be fulfilled by the promise object, the serializer produces an empty array which results in incorrect representation of the relationship to be informed to the backend.
The offending logic appears to be that the promise object which implicitly has ID references to the eventual records that will be retrieved to fulfill the relationship simply returns an empty array when the property record (the PromiseArray object) returns mapBy('id') before those resolutions have been loaded.
This is problematic for representing the relationship state of the model being saved since whether the model eventually resolved those hasMany relationships or not for use should not inform an update operation for the model record where the relationship mapping for affected hasMany property gets reset to empty.
In order to work-around this issue, I've used the below snipped as a hack by extending the RESTSerializer and having the serializer skip the unfulfilled hasMany relationships and not including it in the resulting PUT operation.
The above hack only works if the server-side backend can properly deal with PUT operations where specific properties are not included in the JSON payload.
I'm thinking the proper fix would be to directly alter the PromiseArray used in the context of hasMany to always return all of the IDs (whether fulfilled or not by the given model) when mapBy('id') is called on it so that it does not improperly inform state about the hasMany property being empty. I've dug a little and it seems that this particular scenario may require a bit of creativity since technically there are no explicit records to iterate in a forEach to apply the mapping to extract out the array of record IDs... yet.
I've encountered this issue in
ember-data 1.0.0-beta.8
but upon brief scan through latest code it looks like it may still be affecting current snapshots.Your comments/feedback will be welcome for proper workaround as necessary in this scenario. If current behavior is actually the expected behavior, would like rationale on that as well.
The text was updated successfully, but these errors were encountered: