Thanks @Spencer_Price. Your input was a huge help in my understanding what’s happening here. I’m on
ember-data 2.15.0, which seems like it should support the behavior you pointed out.
I think I see why
destroySync is not called in my scenario.
My record has an id of
32. Let’s say I do my soft-delete and then (after a couple seconds) I go to create a record that will result in
32 being reactivated/revived on the server.
createRecord is invoked on the “new” record,
_existingInternalModelForId is invoked to see if the record already exists in the store.
If I add some logging, I see that my deleted record is still in the store.
.get(id) call does not return the model. The reason it is not returned is because that
get(id) is null, because the record was deleted! I do not have the
id anymore. As far as the user’s concerned, the record is gone and so there is no
id available when we do that lookup.
save() my record, and the server returns my reactivated record
32, a different
_existingInternalModelForId check does return the internalModel this time around. At this point, we have the id from the server, so it can find it in the
This is where the assertion is thrown.
The assertion fails the
=== test. I guess that check is done as an
=== to validate that the internal model is the same as the existing internal model? I don’t know when that would ever actually be true though. Maybe on updates?
One workaround might seem to be that I hold on to the ids after I soft delete, but the weird thing is that even if I manually pass
createRecord, I still fail with a different error when calling
_existingInternalModelForId. The record is found on create if I do that, but for whatever reason, it doesn’t pass the
Despite all of that, I think the fundamental problem is that, even after the record is destroyed async, the identityMap (from what I can tell) never gives up the reference to the deleted record. I fear I may have to hack at that map to clear the record out.