Skip to content
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

[BUGFIX] destroyRecord should also unload #5455

Conversation

fivetanley
Copy link
Member

It seems common for APIs to return a paylaod when deleting a record.
Although there is a test for when undefined is returned from
deleteRecord in the adapter here: https://github.com/emberjs/data/blob/master/tests/integration/records/delete-record-test.js#L87

There are currently no tests showing what happens when you return a
payload. It seems like the correct behavior for destroyRecord should be
deleteRecord + save + unloadRecord.

@fivetanley fivetanley requested a review from runspired April 26, 2018 17:58

env.adapter.deleteRecord = function() {
return EmberPromise.resolve({
data: {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's important to note that no matter what this value is, as long as it is not undefined, the test seems to still fail.

@runspired runspired force-pushed the record-not-removed-when-payload-returned-from-adapter-method branch from bb70fbb to 35cc95f Compare May 21, 2018 00:41
@runspired runspired changed the title failing test for record not unloaded when a payload is returned [BUGFIX] destroyRecord should also unload May 21, 2018
Copy link
Contributor

@runspired runspired left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussing with the team, we resolved that destroyRecord should indeed complete the process.

However, #5472 surfaces inadequate test coverage and bugs, we will need to fast-follow with a fix for such.

@fivetanley fivetanley force-pushed the record-not-removed-when-payload-returned-from-adapter-method branch from 35cc95f to 8f93c0d Compare May 30, 2018 21:00
@fivetanley fivetanley force-pushed the record-not-removed-when-payload-returned-from-adapter-method branch 2 times, most recently from 75e5638 to 1b84fb5 Compare June 27, 2018 23:16
@runspired runspired force-pushed the record-not-removed-when-payload-returned-from-adapter-method branch 2 times, most recently from 8bde815 to f40c60d Compare July 27, 2018 22:29
fivetanley and others added 7 commits August 28, 2018 14:44
It seems common for APIs to return a paylaod when deleting a record.
Although there is a test for when `undefined` is returned from
`deleteRecord` in the adapter here: https://github.com/emberjs/data/blob/master/tests/integration/records/delete-record-test.js#L87

There are currently no tests showing what happens when you return a
payload. It seems like the correct behavior for destroyRecord should be
`deleteRecord` + `save` + `unloadRecord`.
…Record + save

refactor delete-record-test to new style

add assertion messages
@btecu
Copy link
Contributor

btecu commented Nov 23, 2020

Any progress here?

@snewcomer
Copy link
Contributor

@btecu We have a few PRs here (one of which is a direct port of this PR) and are quite close. Just need to put in the time to review.

#7226 will unblock #7258

Hopefully going to review the native model refactor today.

@runspired
Copy link
Contributor

Closing in favor of #7258

@runspired runspired closed this Apr 23, 2021
@runspired runspired deleted the record-not-removed-when-payload-returned-from-adapter-method branch November 29, 2022 07:51
@runspired runspired restored the record-not-removed-when-payload-returned-from-adapter-method branch November 29, 2022 07:51
@runspired runspired deleted the record-not-removed-when-payload-returned-from-adapter-method branch November 29, 2022 07:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants