Skip to content
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

[BUGFIX beta] Overhaul queryRecord #4300

Merged
merged 1 commit into from
May 3, 2016
Merged

[BUGFIX beta] Overhaul queryRecord #4300

merged 1 commit into from
May 3, 2016

Conversation

pangratz
Copy link
Member

@pangratz pangratz commented Apr 5, 2016

Currently the use case for store.queryRecord is not communicated very
well and there has been some confusion on what the expected server
response should look like (array, or an object).

There are several issues with the current code base:

  • in general, if the serializer returns an array for the primary data
    returned by normalizeQueryRecordResponse, then store.queryRecord
    resolves with an array
  • if rest serializer is used and an array is returned by the adapter,
    then the first entry of the array is used as primary data and
    store.queryRecord resolves with the first record
  • if json-api serializer is used and the primary data is an array, then
    store.queryRecord resolves with an array of the primary records
  • the API documentation for queryRecord is similar to query and
    doesn't indicate when this method should be used in contrast to
    store.query and getting the first record of the array
  • an assertion for the payload returned by the adapter for queryRecord
    not being an empty object has been added in 2.4, which is a regression
    to the behavior of 2.3

This commit addresses the above issues and makes the following changes:

  • add assertion that store.queryRecord never resolves with an array
  • add deprecation warning for the rest-serializers' queryRecord, if an
    array is returned instead of a single record
  • removes the assertion that the returned payload from the adapter for
    queryRecord is not an empty object
  • add assertion within json-api serializer that the primary data of the
    normalized response is not an array

I am not so sure about the deprecation for the rest-serializer, since it looks like currently also findRecord works when an array is returned (see this test). But since json-api-adapter doesn't allow data: [...] responses for queryRecord, this seems like an inconsistency which is a little surprising IMHO ¯\_(ツ)_/¯ .

This addresses issues raised in #3977, #4227 and #4255.

The request is made through the adapters' `queryRecord`:

```javascript
// app/adapters/application.js
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe pointing to app/adapters/user.js would be better here ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 You're absolutely right!

@pangratz
Copy link
Member Author

pangratz commented Apr 6, 2016

Thanks for the feedback @sly7-7!

@sly7-7
Copy link
Contributor

sly7-7 commented Apr 6, 2016

I think this is a good answer to related issues, disambiguate, and making the things consistent, I'm all for it

@pangratz
Copy link
Member Author

This has been discussed in the team meeting and overall the taken approach looks good.

I will take a look at #4310 to see if it can be addressed with this PR as well.

assert('Expected the primary data returned by the serializer for a `queryRecord` response to be a single object but instead it was an array.', false, {
id: 'ds.serializer.json-api.queryRecord-array-response'
});
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are your thoughts on doing this in normalizeQueryRecordResponse?

@pangratz
Copy link
Member Author

I've updated this PR to address the following issues:

  • put assertion for queryRecord being an array in the json-api serializer from _normalizeResponse to normalizeQueryRecordResponse, which is a better place as pointed out by @bmac 👍
  • remove assertion for payload not being empty in the _queryRecord method of finder.js. This assertion (introduced in Store._find asserts adapterPayload not empty #3916) caused a regression which has been reported in Can't return null to queryRecord anymore #4310. Removing the assertion allows to return an empty object again, when the rest adapter is used. Tests for store.queryRecord using the rest and json-api adapter have been added, so the expected behavior for those methods are tested and future regressions are caught.
  • updated the documentation for store.queryRecord to point out the behavior: the returned promise resolves with either the found record or null when the adapter returned nothing for the primary data

@taras
Copy link

taras commented Apr 25, 2016

Just to clarify the clarification, does this PR ensure that queryRecord always returns a single object and not an array?

@pangratz
Copy link
Member Author

Just to clarify the clarification, does this PR ensure that queryRecord always returns a single object and not an array?

@taras yes, store.queryRecord will always resolve with a single record. Is that what you meant?

@taras
Copy link

taras commented Apr 25, 2016

Cool, thank you :)

@bmac bmac self-assigned this Apr 28, 2016
if (Array.isArray(normalized.data)) {
assert('Expected the primary data returned by the serializer for a `queryRecord` response to be a single object but instead it was an array.', false, {
id: 'ds.serializer.json-api.queryRecord-array-response'
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of wrapping this in an if block should we replace false with !Array.isArray(normalized.data) so it gets stripped correctly is a prod build?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely! Don't know why I chose the if here 😕

Currently the use case for `store.queryRecord` is not communicated very
well and there has been some confusion on what the expected server
response should look like (array, or an object).

There are several issues with the current code base:

- in general, if the serializer returns an array for the primary data
  returned by `normalizeQueryRecordResponse`, then `store.queryRecord`
  resolves with an array

- if rest serializer is used and an array is returned by the adapter,
  then the first entry of the array is used as primary data and
  `store.queryRecord` resolves with the first record

- if json-api serializer is used and the primary data is an array, then
  `store.queryRecord` resolves with an array of the primary records

- the API documentation for `queryRecord` is similar to `query` and
  doesn't indicate when this method should be used in contrast to
  `store.query` and getting the first record of the array

- an assertion for the payload returned by the adapter for `queryRecord`
  not being an empty object has been added in 2.4, which is a regression
  to the behavior of 2.3

-----------------------------------------------------------------------

This commit addresses the above issues and makes the following changes:

- add assertion that `store.queryRecord` never resolves with an array

- add deprecation warning for the rest-serializers' `queryRecord`, if an
  array is returned instead of a single record

- removes the assertion that the returned payload from the adapter for
  `queryRecord` is not an empty object

- add assertion within json-api serializer that the primary data of the
  normalized response is not an array
@bmac bmac merged commit 581781c into emberjs:master May 3, 2016
@bmac
Copy link
Member

bmac commented May 3, 2016

Thanks @pangratz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants