-
-
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
Store._find
asserts adapterPayload
not empty
#3916
Store._find
asserts adapterPayload
not empty
#3916
Conversation
1012f3b
to
2460ada
Compare
@@ -77,6 +82,7 @@ export function _findHasMany(adapter, store, internalModel, link, relationship) | |||
promise = _guard(promise, _bind(_objectIsAlive, internalModel)); | |||
|
|||
return promise.then(function(adapterPayload) { | |||
Ember.assert("You made a `findHasMany` request for a " + internalModel.modelName + "'s `" + relationship.key + "` relationship, using link " + link + ", but the adapter's response did not have any data", payloadIsNotBlank(adapterPayload)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that could use a better assertion. What adapter are you using?
--@bmac
What would you suggest?
These assertions look great @seanpdoyle. Do you mind adding tests to make sure the assertions are called when the payload is |
@bmac I think I'll need some guidance. I'm surprised that these assertions caused test failures to begin with. |
a95adcd
to
bfed007
Compare
@@ -56,6 +60,7 @@ export function _findMany(adapter, store, typeClass, ids, internalModels) { | |||
promise = _guard(promise, _bind(_objectIsAlive, store)); | |||
|
|||
return promise.then(function(adapterPayload) { | |||
Ember.assert("You made a `findMany` request for a " + typeClass.typeClassKey + " with ids " + ids + ", but the adapter's response did not have any data", payloadIsNotBlank(adapterPayload)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bmac how can I exercise this assertion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seanpdoyle I would follow the pattern used in this test of stubbing the adapter method to return a value that triggers the assertion then using the expectAssertion
helper to test that it is called.
data/tests/integration/adapter/queries-test.js
Lines 47 to 63 in 1d5dfa1
test("The store asserts when query is made and the adapter responses with a single record.", function(assert) { | |
env = setupStore({ person: Person, adapter: DS.RESTAdapter }); | |
store = env.store; | |
adapter = env.adapter; | |
adapter.query = function(store, type, query, recordArray) { | |
assert.equal(type, Person, "the query method is called with the correct type"); | |
return Ember.RSVP.resolve({ people: { id: 1, name: "Peter Wagenet" } }); | |
}; | |
assert.expectAssertion(function() { | |
Ember.run(function() { | |
store.query('person', { page: 1 }); | |
}); | |
}, /The response to store.query is expected to be an array but it was a single record/); | |
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bmac unfortunately, there isn't a store
operation that maps directly to this one like the others.
For instance, adapter.findRecord
maps to store.find
, adapter.query
maps to store.query
(and maybe store.queryRecord
?).
In this case, isn't findMany
used to coalesce find requests?
Would I be able to exercise adapter.findMany
with a store.query({ ids: [1,2,3] })
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bmac I've tried the following:
adapter.findMany = () => Ember.RSVP.resolve({});
assert.expectAssertion(() => {
run(() => store.query('person', { ids: [1, 2] }));
}, /the adapter's response did not have any data/);
But it didn't raise an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bmac which store
operation maps to a findMany
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe you can trigger it by setting coalesceFindRequests: true
on the adapter then making 2 findRecord
requests in the same run loop.
assert.expectAssertion(() => {
run(() => {
store.findRecord('person', 1);
store.findRecord('person', 2);
});
}, /the adapter's response did not have any data/);
352ff57
to
2e5cfae
Compare
Currently, [Store._find][find] only asserts that the `adapterPayload` is non-null (i.e. `{}` is a valid payload). This commit forces the `adapterPayload` to be non-empty. When TDDing with Mirage, `adapterPayload` is often `{}`, which sneaks through the asserts and ends up as a non-descriptive: ``` Assertion Failed: You must include an 'id' for undefined in an object passed to 'push' ``` Which is triggered in [Store._pushInternalModel][_pushInternalModel], which is a few method invocations away from the source of the issue. [_pushInternalModel]: https://github.com/emberjs/data/blob/f1ccad8ab9356dd51f44d63585c27d8bb4ec9c3a/packages/ember-data/lib/system/store.js#L1709 [find]: https://github.com/emberjs/data/blob/f1ccad8ab9356dd51f44d63585c27d8bb4ec9c3a/packages/ember-data/lib/system/store/finders.js#L27
2e5cfae
to
a51bea9
Compare
run(() => { | ||
store.findRecord('person', '1'); | ||
store.findRecord('person', '2'); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bmac 👍 that did the trick.
@bmac what's stopping this from being merged? Is there anything else I can do? |
Sorry, @seanpdoyle I've been very busy recently and hadn't had a chance to review this pr. Looking at it now. |
…t-empty `Store._find` asserts `adapterPayload` not empty
Thanks @seanpdoyle. Sorry for the delay. |
Currently, Store._find only asserts that the
adapterPayload
isnon-null (i.e.
{}
is a valid payload).This commit forces the
adapterPayload
to be non-empty.When TDDing with Mirage,
adapterPayload
is often{}
, which sneaksthrough the asserts and ends up as a non-descriptive:
Which is triggered in Store._pushInternalModel,
which is a few method invocations away from the source of the issue.