Set TTL on record when it is fetched, and reload after it expires #545

Closed
darthdeus opened this Issue Dec 22, 2012 · 12 comments

Projects

None yet

6 participants

@darthdeus
Ember.js member

Since Ember applications are supposed to be long living, some of the data which is stored in the identity map might become outdated.

There are simple cases when this can be solved by periodically reloading the data manually. For example some kind of a news section, which is loaded just from one place in the application.

But how do we handle this if we're not sure where the data came from? This is the case of data loaded from relationships. In that case you can't simply replace the content every few minutes, because you don't know where the data came from, and it is only stored in the identity map.

It would be good if we could specify something like a TTL for a given model, and it would get reloaded after it expires automatically, no matter where it came from. This would work well with the databindings, as they would just automatically propagate throughout the application and update everything.

Since sending one request for each model which expires via the TTL could cause performance issues, they might just queue up and then do a bulk fetch like GET /foo?ids=[1,2,3,4].

A first step here would be to have a reload() method on a model, which would just do GET /foo/:id and reload it's attributes from the server. Or even reload() on the whole model, which would expire all of the instances of that given type.

@darthdeus
Ember.js member

Another cool thing which is related to this would be to allow force reloading data from an external source. For example creating a websocket connection, which would push updates to the client, and it could just update the data directly in the identity map, so that the user would have the same data as the server has, without additional request overhead.

@kurko

I agree with the reloading, but in my opinion, I don't think it should be automatic by convention, but by configuration. I imagine that in most cases, devs will want to have data sitting there until something specific triggered.

@darthdeus
Ember.js member

@kurko yep, I imagine it would be something like this

App.store.ttl({
  users: "5m",
  posts: "1h"
});
@darthdeus
Ember.js member

I guess I should probably ask the gods if this is worth pursuing. It'll probably take me some time to get a working prototype, or if anyone has any suggestions where to start, I'll gladly hear them :)

/cc @tomdale @wycats

@stefanpenner
Ember.js member

I for one think this is a very interesting idea. But it does feel like poor mans websocket push.

@darthdeus
Ember.js member

Websockets are not something you want to introduce in every application, as they aren't that reliable and supported. Reloading via HTTP works 100% of the time.

@wagenet
Ember.js member

@darthdeus Some of us discussed something like this recently. I know @trek especially was in favor.

@darthdeus
Ember.js member

Glad to hear that :) What did you guys come up with?

@doxavore

I know Ember has seen a lot of changes in the last month - have there been any discussions about this sort of feature outside of this GitHub issue? Either how to bring this to ember-data proper, or some suggestions that people are using in their apps today?

@darthdeus
Ember.js member

@doxavore .reload() was added, but nothing about automatically invalidating and reloading after a TTL.

@akshayrawat

Data sync across clients is such a common scenario. I reckon its a bit too early to talk about it though ?

@wagenet
Ember.js member

The RESTAdapter has support for something similar on find all queries. For individual records, it seems easy enough to add your own timer that calls reload.

@wagenet wagenet closed this Aug 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment