-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[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.
@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 emberjs/data#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 emberjs/data#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 emberjs/data#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 emberjs/data#4077 (comment)
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
andstore._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.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 inAdapterPopulatedRecordArray.loadRecords
, so it is no longer neededwith this new implementation.