model.unloadRecord causes Uncaught TypeError: Cannot read property 'eachAttribute' of null #5343
Comments
alexmiddeleer
changed the title
|
Unloading the record from the In my case I found out that it is triggered due to a |
|
Repoduced in ember-data 3.0.1 |
|
I have the same problems. If I do that it works : I tried to trace the code, and apparently, unloadRecord somehow schedule a fetch before the object is destroyed. I think it is because the hasMany relationship is changed ( record I'm trying to unload has a belongsTo ). |
|
I get the same error, when I try to load a relationship by ID, that For instance: {
id: '1',
type: 'post',
relationships: {
author: { id: '2', type: 'author' }
}
}Now, if I access the To make things worse, this appears to put Ember Data in an invalid state, that requires a page reload. |
|
I've had issues similar to this with all releases after 2.12.2 and therefore have not been able to upgrade ember-data past that release |
|
I've got an app on 3.0 and can consistently reproduce this error. Would be happy to help debug if anyone wants to provide me with some direction. |
When fetching records, cancel internal model destruction if it is
scheduled, ie if the model is dematerializing because it was unloaded.
It is not possible to construct snapshots for dematerializing internal
models. Prior to this commit, this could happen when fetching a record
in the same runloop that it was unloaded. A straightfoward way of
getting into this state was via
```
store.findRecord('book', 1).then(b => b.unloadRecord)
```
when the model is already cached in the store. Under these conditions,
the fetch is scheduled, then the promise fulfills with the cached record
and is unloaded and *then* the scheduled fetch is flushed.
[fix emberjs#5343]
Invalidates link promises when inverse records are unloaded. Subsequent fetches of a `hasMany` unloaded in this way will load from the link again, rather than loading whatever ids were returned from the prior link load. [fix emberjs#5343]
|
@hjdivad Thanks for the PR - looks like the problem is fixed in our app using |
When fetching records, cancel internal model destruction if it is
scheduled, ie if the model is dematerializing because it was unloaded.
It is not possible to construct snapshots for dematerializing internal
models. Prior to this commit, this could happen when fetching a record
in the same runloop that it was unloaded. A straightfoward way of
getting into this state was via
```
store.findRecord('book', 1).then(b => b.unloadRecord)
```
when the model is already cached in the store. Under these conditions,
the fetch is scheduled, then the promise fulfills with the cached record
and is unloaded and *then* the scheduled fetch is flushed.
[fix emberjs#5343]
When fetching records, cancel internal model destruction if it is
scheduled, ie if the model is dematerializing because it was unloaded.
It is not possible to construct snapshots for dematerializing internal
models. Prior to this commit, this could happen when fetching a record
in the same runloop that it was unloaded. A straightfoward way of
getting into this state was via
```
store.findRecord('book', 1).then(b => b.unloadRecord)
```
when the model is already cached in the store. Under these conditions,
the fetch is scheduled, then the promise fulfills with the cached record
and is unloaded and *then* the scheduled fetch is flushed.
[fix emberjs#5343]
When fetching records, cancel internal model destruction if it is
scheduled, ie if the model is dematerializing because it was unloaded.
It is not possible to construct snapshots for dematerializing internal
models. Prior to this commit, this could happen when fetching a record
in the same runloop that it was unloaded. A straightfoward way of
getting into this state was via
```
store.findRecord('book', 1).then(b => b.unloadRecord)
```
when the model is already cached in the store. Under these conditions,
the fetch is scheduled, then the promise fulfills with the cached record
and is unloaded and *then* the scheduled fetch is flushed.
[fix #5343]
(cherry picked from commit 7444444)
When fetching records, cancel internal model destruction if it is
scheduled, ie if the model is dematerializing because it was unloaded.
It is not possible to construct snapshots for dematerializing internal
models. Prior to this commit, this could happen when fetching a record
in the same runloop that it was unloaded. A straightfoward way of
getting into this state was via
```
store.findRecord('book', 1).then(b => b.unloadRecord)
```
when the model is already cached in the store. Under these conditions,
the fetch is scheduled, then the promise fulfills with the cached record
and is unloaded and *then* the scheduled fetch is flushed.
[fix #5343]
(cherry picked from commit 7444444)
|
I'm having the exact same issue as @buschtoens mentioned here. Any idea how to work around it? |
When fetching records, cancel internal model destruction if it is
scheduled, ie if the model is dematerializing because it was unloaded.
It is not possible to construct snapshots for dematerializing internal
models. Prior to this commit, this could happen when fetching a record
in the same runloop that it was unloaded. A straightfoward way of
getting into this state was via
```
store.findRecord('book', 1).then(b => b.unloadRecord)
```
when the model is already cached in the store. Under these conditions,
the fetch is scheduled, then the promise fulfills with the cached record
and is unloaded and *then* the scheduled fetch is flushed.
[fix #5343]
This is after calling
findRecordthenunloadRecordon the result. We are upgrading to ember 2.18 and ember-data 2.18, and this appears to be a regression.Twiddle reproduction:
https://ember-twiddle.com/c16533267ff13353b25498fac4d05ca3?fileTreeShown=false&numColumns=2&openFiles=controllers.application.js%2Ctemplates.application.hbs
Possibly a duplicate of #4963, but that was supposedly fixed a while ago.
The code that doesn't work is this:
The text was updated successfully, but these errors were encountered: