unload should invalidate async hasMany: failing test #5353
Conversation
|
Might be related to #5328 |
|
@sly7-7 I think the problem here is partly due to me not understanding the new async handling. The first assert of the count not being correct after the unload could probably be ignored. But the final exception might be the real problem. Where ember-data now correctly is able to reload an dematerialized record that is still in the ManyArray, it fails to handle the case when a record is deleted on the server side. The rejected fetch will result in a complete failure now, while this could actually be a valid response. So maybe this test should be renamed into 'async relationship can handle server side deletion' or something like that? |
|
Does anybody have any idea on how a rejection in a loading ManyArray should be handled in async relationships? The async part makes it valid to have changes on the server side once the data is asked for. So I think ember-data should play well with any record that is rejected. The findMany part only gives warnings if you don't include deleted items as far as I can tell: https://github.com/emberjs/data/blob/master/addon/-private/system/store.js#L892 We don't coalesce records in our plugin and this path seems to throw exceptions that are not caught and I'm not really sure if this will actually update the ManyArray if it would be used with a |
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#5353]
This simulates the problems I'm having when trying to debug #5343
As far as I could tell the new behaviour for async relationships is not to mark unloaded items as deleted, but to use
invalidate+refetchas mentioned here: 6e8a236But I'm having trouble understanding whether the invalidate should be done by the ember-data user, or by ember-data.
I feel this should be ember-data's job, but this test has one line in comment where the user could
hasMany(....).reload()to refetch the data to fix the problem. But that feels like a bad solution.