Repository navigation
[CLEANUP beta] Change the way metadata in response is stored on record array - #4077
Conversation
|
Looks good to me. @wecc can your also review this pr? |
|
I am planning on opening an additional PR to add |
|
I'd say do it in a separate pr. |
|
Ok, I'll wait for this PR to be accepted first, as it will tie into the same |
|
Thanks for the PR @danmcclain! It's nice to see I'm not gonna block this due to ⬆️, the code is private and easily changed if needed. It's very nice to get rid of Can you prefix the commit with |
…d array
The previous implementation of inserting metadata from an ajax response
onto a record array used the store as temporary storage for the metadata
via `store._metadataFor` and `store._setMetadataFor`. Although rare, this could
store the wrong value on the record array due to a race condition, as
the metadata was stored based on the query's model's name. This moves
the storing of metadata to `AdapterPopulatedRecordArray.loadRecords`
since, at the time that that method is called, the payload is present,
so we don't have to use `store.{_setMetadataFor,_metadataFor}`.
`store._metadataFor` was only used in
`AdapterPopulatedRecordArray.loadRecords`, so it is no longer needed
with this new implementation.
danmcclain
changed the title
|
@wecc Updated! I was thinking the same (just passing Thanks |
|
I take that back, I never pushed it until now. Updated for real @wecc |
[CLEANUP beta] Change the way metadata in response is stored on record array
|
I was using @vanadar's temporary solution to get meta for a single record. Since this PR it no longer works. Is there an alternative? |
|
Similar issue, the workaround in #4115 now no longer works. |
|
@duizendnegen hack: // models/base.js
_meta: computed(function() {
return this._internalModel.type.____meta;
}).volatile()// serializers/application.js
extractMeta(store, typeClass) {
let meta = this._super(...arguments);
typeClass.____meta = meta;
return meta;
},// usage
myModel.get('_meta'); |
no issue - Ember Data does not support accessing meta data included in the response to single-record requests such as save/delete - approach to allow it taken from warp-drive-data/warp-drive#4077 (comment)
no issue - Ember Data does not support accessing meta data included in the response to single-record requests such as save/delete - approach to allow it taken from warp-drive-data/warp-drive#4077 (comment)
no issue - Ember Data does not support accessing meta data included in the response to single-record requests such as save/delete - approach to allow it taken from warp-drive-data/warp-drive#4077 (comment)
no issue - Ember Data does not support accessing meta data included in the response to single-record requests such as save/delete - approach to allow it taken from warp-drive-data/warp-drive#4077 (comment)
5 participants
The previous implementation of inserting metadata from an ajax response
onto a record array used the store as temporary storage for the metadata
via
store._metadataForandstore._setMetadataFor. Although rare, this couldstore the wrong value on the record array due to a race condition, as
the metadata was stored based on the query's model's name. This moves
the storing of metadata to
AdapterPopulatedRecordArray.loadRecordssince, at the time that that method is called, the payload is present,
so we don't have to use
store.{_setMetadataFor,_metadataFor}.store._metadataForwas only used inAdapterPopulatedRecordArray.loadRecords, so it is no longer neededwith this new implementation.