Cache invalidated trigger

[kenjiqq]

Now that ejectAll also invalidates queries that have been run, what do you think about some method or something similar to lastModified to detect if the cache has been invalidated. So that code that uses the resource can rerun their find/findAll queries.

[jmdobry]

This isn't part of the public API, but you could do something like this:

DS.defineResource('post');

$scope.$watch(function () {
  return DS.store.post.completedQueries;
}, function (cur, prev) {
  // check if prev has a query that is not in cur
  // if so, rerun that query
}, true);

[kenjiqq]

Yeah, that would be one solution.
But you would get situations where you are rerunning queries that are no longer needed, stuff that was run by code that are no longer running for instance.

I guess it would be possible to do something like this for every place in the code you run a findAll

var query = { ... }
DS.findAll('post', query).then(function() {
  // Bind some stuff to the scope
  $scope.$watch(function () {
    return DS.store.post.completedQueries;
  }, function (cur, prev) {
    if( /* cur not contains query */ ) {
      //  rerun findAll
    }
  }, true);
}

It feels to me like you would need this a lot of places in your code, though. Basically anywhere you use a resource you would need it, or else you end up with just an empty array of elements if the cach is cleared, and nothing that triggers the findAll to rerun

[jmdobry]

completedQueries simply holds the JSONified params that have been passed to findAll. The key is the JSONified params and the value is the timestamp of when the query completed. These key-value pairs can be removed from completedQueries in several places:

1. Calling ejectAll and passing the same params as a cached query
2. Calling ejectAll without passing any params
3. Manually - delete DS.store.post.completedQueries[angular.toJson(params)]

In every one of those cases the developer is explicitly causing the query to be invalidated with his or her own code. Therefore, there is no need to "listen" for when queries are invalidated, becuase the developer is doing the invalidating him or herself. There aren't any cases where a cached query would be invalidated by angular-data without being directed to do so by the developer.

So, if the developer directly deletes a cached query, then the developer knows the query is being invalidated, and (presumably in the same location in the code) the developer can be the one to make the query again.

While an addition to angular-data's API would make more sense if queries were invalidated by an event, for example, I don't see a reason to add anything to angular-data's API that would tell the developer when a query has been invalidated.

[kenjiqq]

I agree that in all cases where the queries are being invalidated it is an explicit action by the developer of the application. But I can see many situations where this does not happen in the same location as the code that uses the resource.

The resources are global, and could and most likely will be used it different parts of the application. If in one of these parts something happens that requires that the resource should be invalidated and refetched, then it will be easy for that code to rerun any queries that are related to that context. But other parts of the code that use the same resource, with other queries for instance, would not know about this and when they their lastModified watches trigger to rerun their filter methods they could end up with empty results or only partial data.

Right now i am handling this by using Angulars broadcast system to propagate an event that informs about the cache invalidate. Maybe cache invalidation is a pretty uncommon situation and that it's fine that this requires a solution outside of angular-data.

I guess another way to handle it could be to write my own bindAll that uses findAll on the watch trigger instead of filter, to ensure that the query is always run if the resourceModifications was an ejectAll.

[jmdobry]

This could potentially be handled by what's described in #117

[jmdobry]

Now that you can get a handle on the DS.eject event implemented here I'm going to consider this issue closed.