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.
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.
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.
@kurko yep, I imagine it would be something like this
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
I for one think this is a very interesting idea. But it does feel like poor mans websocket push.
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.
@darthdeus Some of us discussed something like this recently. I know @trek especially was in favor.
Glad to hear that :) What did you guys come up with?
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?
@doxavore .reload() was added, but nothing about automatically invalidating and reloading after a TTL.
Data sync across clients is such a common scenario. I reckon its a bit too early to talk about it though ?
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.