-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
destroyRecord regression in 2.13.x #4995
Comments
This is still happening on latest |
I wound up having to change our UI to send a manual DELETE request, rather than use the destroyRecord api. |
Any progress here on a fix? This issue has gotten to be a big problem while trying to upgrade from 2.13.x to 2.15.x (currently we're locked on ED 2.12.x while on Ember 2.13.x, though having such a large disparity onward - 2.12 ED and 2.15 Ember - feels misguided, so this is a blocker for us on upgrading Ember). |
@yads your solution is weird, destroyRecord sends a delete request, and then on success it unloads the record. I'm unsure how that differs from what you've done, but maybe that also points to where we need to look to fix. |
As far as I can tell, committing a record as being deleted also marks it in the store as having state 'root.deleted.saved'. When the store sees it again via a reload query, it seems to then have an issue with this. Manually sending a DELETE request, does not mark it in the store as having been deleted. |
Oh, so you mean not via |
I'm following this because we also ran into a similar issue. I think is because when you unload a record it no longer ends up in Edit: Actually @yads never said if he unloads the record or just leaves it alone, so maybe I preemptively assumed that. |
@runspired it looks like that issue you referenced is essentially the same. The reason we are reloading the record is because sending the DELETE request merely starts the deletion process, which can take some time depending on the entity being deleted. So we want to reload the data to make sure the user is seeing the new status of the entity. |
I believe we are experiencing similar behavior:
In our case, adding an |
If @thec0keman's suggestion doesn't work, I did something along the lines of what is discussed in #4972.
|
I started experiencing a regression after upgrading to 2.13.x from 2.12.2. The error happens when calling destroyRecord, then later querying records. Here is a test case route that reproduces the issue for me:
The gotcha in our system is that the DELETE handler does not immediately delete the record, but marks the record for deletion. So it will still be returned in query calls until it's finished being deleted.
The error that I am getting in 2.13.1 is
The text was updated successfully, but these errors were encountered: