Data: Fix semantics of `findRecord` vs. `queryRecord` or add another `query*` method

[ohcibi]

Currently findRecord and queryRecord differ in their signature and the way the requests are made (if findRecord makes a request).

findRecord("foo", 1) will request /foos/1 while queryRecord("foo") (which takes no ID as a parameter) will request /foos without any ID. I understand that queryRecord was called queryOne before. It was a way better name (given that findRecord exists), why was it renamed?

For the purpose of this issue I'd say that ember-data needs a query*-method that builts the url like findRecord does and has support for adding query params. I would call it queryRecord and rename the current queryRecord back to queryOne (which I would do no matter if my desired method ever exists as queryRecord is misleading)

[bmac]

Hi @ohcibi. Thanks for this question. First to clarify a few things findRecord is intended to be used to make a request for a single record when the id is know. queryRecord is intended to be used to make a request for a single record when the id is not know (for example when using some other unique key to build the request url).

Second I want to talk a little bit about why Ember Data doesn't have a method that builds the url like findRecord does and has support for adding query params because historically, the Ember Data team has been reluctant to add a method like this but I don't think the reasons are explained anywhere.

To understand why this method is unlikely to exist we need to first talk about the store. One of the primary advantages of Ember Data's store is it allows developers to quickly return a cached record if the application no matter where in the application that record was originally requested.

In order to achieve these benefits the store does have some assumptions

• every record can be uniquely identified by its type and id.
• once a record has been loaded into the store all of the data is loaded.

The fear is that allowing users to specify arbitrary query params thought the store.findRecord methods it would be possible to get the server to return records in a partially loaded state. This partially loaded state would make it easy for developers to introduce bugs where if depending on the route a user took though an application it might be possible for Ember Data's store to return a partially loaded record when the original developer expected a fully loaded record to be returned.

That said, there are some valid use cases where a developer may want to include query params to a request that the Ember Data team would like to support.

The first case is using query params to hint to the server what relationships should be sideloaded. This functionality should be supported by the ds-finder-include feature in a future release.

The other case is sometimes a developer may need to always sending the same query param with every request. This can be achieved by overriding the adapter to always include this query parameter. The added benefit here is it the developer doesn't need to remember to provide this query parameter in every find* method call.

I hope this explanation helps.

[sheriffderek]

That's a helpful explanation @bmac.

I often load all of the data, for a small site in an outer application route. Then, in the sub-routes I peek at the data for pieces / page data / etc - but what I'm curious about is how I would query with a peek approach - such as by category. I don't want to hit the server _again_ if I already have all of the post data.

"Calling store.query() will make a GET request..."

https://guides.emberjs.com/v2.5.0/models/finding-records/#toc_querying-for-multiple-records

[pangratz]

I am going to close this issue as this should be clear now after @bmac's comment above. @ohcibi feel free to reopen if you disagree...

@sheriffderek caching a query is currently not possible in core ember-data, but there is already an issue about that #1966. I've created a ember-twiddle with a simple implementation for a cached query. This should get you started until something similar is added to the core...

[sheriffderek]

@pangratz Thanks for that twiddle

[vasilakisfil]

Hi,

I totally disagree with this direction. ember-data should be more generalized. Sending parameters when asking a specific record (by id) should be easy and possible without having to create a whole new adapter.

Now, if this is not going to be cached due to issues with the ember-data core or fear that the developer will introduce more bugs, I am totally fine with it. But it should be definitely be possible to pass arguments.

Come one people, let's make a great tool and let the developers choose what they want.

[poohitan]

I agree with @vasilakisfil. I also think that at least one more query parameter must be available out-of-the-box along include. It is fields query parameter. It's also described in JSON API specification and it makes sense to use this parameter while finding a single record.