Data Adapter: Only trigger model type update if the record live array count actually changed #15604
Conversation
… count actually changed Fixes emberjs/ember-inspector#690 The issue: In some cases, Ember Data's `peekAll` triggers `arrayContentDidChange` on the record array manager's live record array even if the records didn't change. One example case is when we call `unloadRecord` and then `peekAll` within the same run loop. The `peekAll` will trigger the array observer's `didChange` callback (with zero changes). This is generally harmless as long as we guard against that in our data adapter. Without the guard, we risk causing an infinite recursion because our `didChange` observer itself calls `peekAll`, which in the above scenario will re-trigger the observer and so on.
|
@rwjblue @stefanpenner could this make it into 2.14? Right now it has big negative impact on ember inspector. |
|
+1 on this, it's killing my dev workflow. Is there a temporary workaround? |
|
Chrome freezes for me too - running [email protected] and [email protected]. |
|
This was released in 2.15.2 |
|
@rwjblue When will 2.15.2 release? This is causing an issue in one of our applications as well. |
|
@DLiblik https://libraries.io/npm/ember-source/2.15.2 was out on the 4th and https://libraries.io/npm/ember-source/2.15.3 on the 10th. |
|
@rwjblue My fault - poor question on my part: I meant through ember-cli. Running npm to install [email protected] fails on the version not being available. The releases there also do not list 2.15.2 https://github.com/ember-cli/ember-cli/releases - it might just be that I'm not clear how the two versioning processes sync up. |
|
Ember can be upgraded without having to upgrade Ember CLI. |
Fixes emberjs/ember-inspector#690
The issue:
In some cases, Ember Data's
peekAlltriggersarrayContentDidChangeon the record array manager's live record array even if the records didn't change. One example case is when we callunloadRecordfollowed bypeekAllwithin the same run loop.The
peekAllwill trigger the array observer'sdidChangecallback (with zero changes). This is generally harmless as long as we guard against that in our data adapter. Without the guard, we risk causing an infinite recursion because ourdidChangeobserver itself callspeekAll, which in the above scenario will re-trigger the observer and so on.