Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shouldReloadAll will change in Ember Data 2.0 #79

Closed
broerse opened this issue Jul 19, 2015 · 8 comments
Closed

shouldReloadAll will change in Ember Data 2.0 #79

broerse opened this issue Jul 19, 2015 · 8 comments

Comments

@broerse
Copy link
Collaborator

broerse commented Jul 19, 2015

I get this deprecation warning:
Ember Inspector (Deprecation Trace): The default behavior of shouldReloadAll will change in Ember Data 2.0 to always return false when there is at least one "author" record in the store. If you would like to preserve the current behavior please override shouldReloadAll in your adapter:application and return true.
Do we need to change something? Is the new behavior better?

@fsmanuel
Copy link
Collaborator

The new behavior aims to optimize performance.
There are 4 methods:

The idea in Ember Data 2.0 is to return a cached version immediately and than refetch in the background.

For pouchdb the fetch isn't expensive because we don't need an ajax request. I guess it's best to always reload:

  // Reload behavior
  shouldReloadRecord: function() { return true; },
  shouldReloadAll: function() { return true; },
  shouldBackgroundReloadRecord: function() { return true; },
  shouldBackgroundReloadAll: function() { return true; }

@broerse
Copy link
Collaborator Author

broerse commented Jul 19, 2015

Perhaps we should implement this in the ember-pouch adapter by default.

@fsmanuel
Copy link
Collaborator

👍

@broerse
Copy link
Collaborator Author

broerse commented Jul 19, 2015

I will write a PR for this.

@rsutphin
Copy link
Collaborator

The change watcher already provides automatic refreshing of cached records in a way that's more efficient than this ember-data feature — it updates the store-cached record as soon as it is changed (not just when findRecord is called), and it only updates when it is actually different (instead of making a query every time findRecord is called). So I think returning true from shouldReloadRecord or shouldBackgroundReloadRecord in an ember-pouch app will make the app do more work without benefit. I'd be in favor of having ember-pouch default both of those to false.

shouldReloadAll is trickier and requires more thought. It's easy to say that, since an ember-pouch query is local, it's cheap and therefore it doesn't matter if we do it all the time. But when you have a lot of records of a particular type, it's still slow to deserialize them all. Doing this frequently will make your app noticeably laggy, even if there are no changes. So I'm not sure what the proper default is for this. For the moment, I think it's worth allowing folks who are using ember-data 1.13 to see the deprecation warning and decide for themselves.

@broerse
Copy link
Collaborator Author

broerse commented Jul 19, 2015

@rsutphin Oh, just now saw your comments. I still think enabling the new Reload some time after 2.0 is released is better. .0 versions are not always OK ;-)

rsutphin added a commit to rsutphin/ember-pouch that referenced this issue Jul 23, 2015
… records.

See pouchdb-community#79 and pouchdb-community#80 for discussions of why, and why this covers the individual
record case only.
jkleinsc pushed a commit to HospitalRun/ember-pouch that referenced this issue Jul 29, 2015
… records.

See pouchdb-community#79 and pouchdb-community#80 for discussions of why, and why this covers the individual
record case only.
@rsutphin
Copy link
Collaborator

Addressed by #83.

rsutphin added a commit that referenced this issue Jul 30, 2015
This was in 2.0.3, just forgot to add it to the changelog.
@broerse
Copy link
Collaborator Author

broerse commented Mar 21, 2016

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants