Cache a record when using Query Params in the call?

Ember Data
1

I have got this route retrieving 2 models:

App.PanelRoute = Ember.Route.extend({
     model: function(){
     var topologymin = this.store.find('topologymin');
     var metricmap = this.store.find('metricmap', { param1: 'something'})
     return Ember.RSVP.hash({
            topologymin: topologymin,
            metricmap: metricmap
     });
 });

This makes 2 calls:

localhost/topologymins

localhost/metricmaps?param1=something

If I go to another route and again to this one, it makes again the call with the params, not the other one:

localhost/metricmaps?param1=something

But, as its the same call to retrieve the same records I would like them to be cached like in the other call.

How does it know when to call the server and when its not necessary? Is it possible to do that?

My models:

 App.Topologymin = DS.Model.extend({
      siteGroup: DS.attr('string'),
      sites: DS.hasMany('site')
    });

  App.Metricmap = DS.Model.extend({
      profile: DS.attr('string'),
      link: DS.attr('string'),
      services: DS.attr()
  });
2

Well, I love Ember but unfortunately the caching model i neighter optimal nor well documentated! I already had thoughts about this.

Its is very tricky, since u cant always cache a query! Both, the list of items in the result and the data on the items may have changed since your last call! So it would be necessary to have a way to tell ember data that some query results should be cached! Then u may also need a way to tell ember data that a cached query is outdated! If we think further, we notice that the query should only return additional items, but the data on the existing ones remain the same, u may only want to sent the new items over the network! So maybe we need a way that the Server can sent only a list of ids, and then Ember data has to call a maybe required findMany, if some of the items dont exist yet or are outdated. Well, outdated, a good keyword! The other situation is much more likely: The list of items remains, but on some of them are the data not in sync with the server.

So, over all, we would need a seperated cache for lists of items, and a cache for items (which we already have). We would also require a way to tell ember what should be cached and what not! We also need a way to tell ember some cached date are outdated, for both, lists and items (or both). And finally we need a way to auto update the required data when needed.

This is at least complicated, and I would love to build it myself, but i dont have the required time at the moment or in near future to do it right!

And since this does not be important for the ember community, i guess we have to stay at jQuery or life with the limitations I guess.

Actually, its a reason for me to not use Ember Data at the moment but to load all data manually with jQuery.

3

So what happends if you have a back-end that dinamically generates the records. For example calling it like: url?id1,id2…

What about telling Ember the ids of the records you are asking for with that query, then it should only see which id’s are already in the store and for the ones that are not create the url as showed.

Then you just can define a timer to delete the records from the store in some minutes…

Shouldnt that be easy?

Could I make it transform a findMany(‘model’, [1,2]) call into url?site=1,2 overwritting the adapter or something?

4

Well, the findMany is not the Problem! It does already exist and works well! But thats not a query!

When we look for a query we have two performance intensive steps:

  1. Check which items match the query.
  2. Get theese items.

generelly problematically for the performance is every network request itself, but also to transfer a big amount of data over the network.

On the server the search for the matching items may also load them into the memory, but its also possible that to load the items would require additional work.

so, if we decide to return only an list of ids, and then create a findMany, its very inefficient when we only return very few items which we already have in the store on the server, since the additional data to transfer over the network are less performance intensive then an additional request!

but when we sent hunderts or thousends of items back, its expensive to load them on the server and we may already have most of them loaded into ember, we should only sent the ids and make the additional findMany request since it is less performance intensive then to load and sent all the items we dont need over the network!

Actually, this decision can only be made by the developer for his individual project and individual model and query!

And, a timer to delete records is never ever a good idea!

May we requre the records for hours, but we absolutly know they wont change in years! Then we have absolutly no reason to delete them!

May we have records that are only valid for seconds, but then we should use websockets or something, or just always reload them when the user loads additional data to always have consistent data!

But most important we dont wont to delete the not up-to-date records! A delete in current ember way means that the record does not exist anymore on the client and the server! And we still need this state!

We need something new! A way to mark a records as obsolete! So ember does still know the record, but does also know the data are not up to date! So it should update the record next time we need the data, but not immediatly, since we may never need this record again!

As far as I know we dont have this yet, and this is sad! But we need it for both, records and lists!

5

Agreed. And thank you very much for answering.

I have got a couple of questions.

1- Any opinion with this then? javascript - FindMany overwritten doesn't work. Ember-data - Stack Overflow

“A delete in current ember way means that the record does not exist anymore on the client and the server!”

2- Couldnt we just delete the record cached, so when we ask for it again it will have to call the server?

6

Actually I’m not an expert in ember data since I cant use it because of the limitations. But since u have a very specific question I would advide u to ask it on stackoverflow with the ember and ember-data tags. I’m sure someone can help u!

Also look at the documentation of the RESTAdapter’s findMany and the JSON API!

And no, we cant just delete the Record cached! Well, at least not without changing the ember-data core itself! And I also dont think its a good Idea. I would just mark it as outdated! So ember data can use it to keep relations in sync and stuff. But it should get updated when we access it next time.

I agree that to just delete it is maybe an option! Someone has to think about this before extending ember data with complex caching.