emberjs
Strange behavior of the store sins 3.28.0 or later
Hi. I have a lot of similar and curiously problems, since we used [email protected]. I can't say for sure that we've had the problems since 3.28.0 or later. I'll try to summarize two problems of them briefly here. If you think its better to post a new issue, please let me know.
First problem: I get records from backend by using query to get data for model "test" with filter=xxx and include=a,b,c and the backend delivers the correct entries. Now i get a record of one of this (with findRecord and reload:true) and change a property (attribute) of this entry (without saving the model). Then i do a new query for model "test" with same filter and same include. Now the store should actually replace the changed entry with the reloaded entry (like before 3.28.x). The store ignores the responsed data and do not override/reset the change property.
Only when i do a unloadAll("test") before the second request, the store uses responsed data and overrides. But when i do the complete process of first problem again (after unloadAll), the unloadAll has no effect and the store ignores every new requests/responses.
Second problem: I do the same like first problem. But i additional change a belongsTo-relation from null (unused) to a specific relationship. When i do a query or a findRecord (with reload) again, the belongstTo-relation has the changed specific relationship and not null. The store ignores the new requests and responsed data. unloadAll or unloadRecord has no positive effects. This problem concerns only relations, they not set (null).
When i change a relation from one saved specific realationship to another, the store overrides the relations by using responded data. In this case the unloadAll or unloadRecord has positive effects and resets relation to origin relationship.
The adapter methods (shouldBackgroundReloadAll, shouldBackgroundReloadRecord, shouldReloadAll, shouldReloadRecord) to force reloading have no positive effects.
I think its a important bug - the behavior before 3.28.x was another (and correct working for my opinion).
We need help, very urgent.
Originally posted by @Timbuktu1982 in https://github.com/emberjs/data/issues/7688#issuecomment-948309919
ember-data: 3.28.3 ember: 3.28.1 all packages are up to date.
Additional problem discovered: In rare cases I have the problem that the isDirty state (after findRecord with reload:true) is reset correctly, but a previously made change to a relation (which at this moment has no relationship yet) still contains the changed value instead of having been reset correctly.
Description:
- Load a model with findRecord.
- Change a relation X (which at this moment has no relationship yet) of this model to a specific relationship.
- isDirty => true
- Reload this model with findRecord and reload:true.
- isDirty => false
- Relation X has the same selected relationship like 2.
I'm guessing it could be one of these two:
- https://github.com/emberjs/data/issues/7688
- https://github.com/emberjs/data/issues/7684
Honestly this mostly just sounds like you just noticed how ember-data has always worked. It may be that before you were rolling back the dirty state and now you are not, but by default ember-data has always preserved dirty attribute state and additions of new records to relationships when fresh data is loaded / a record is reloaded.
Also, since relationships have never affected dirty state, I'm curious whether you maybe are using an addon that is attempting to change how ember-data works / used private APIs and has potentially broken against 3.28+?
@Timbuktu1982 Can you try with 3.28.8 and see if the problem persists? (the two issues mentioned above have been fixed in that release, either of which may solve your problem)
Yeah, i will test in the next days and give you response whether it works or fails again...
@runspired Awesome work on Ember Data lately, have you considered adding a $200 sponsoring tier? 😄
Sorry, I haven't had a chance to test this further yet. I'll put it on my agenda for the next few days. I'll be in touch. Thanks in advance
closing, happy to revisit if there still turns out to be something to resolve