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

[DEPRECATION] missing data for sync relationships should not be considered empty #8816

Closed
runspired opened this issue Aug 17, 2018 · 4 comments

Comments

@runspired
Copy link
Contributor

Currently, if a synchronous relationship receives a payload containing no information about it's state, we initialize the relationship as if it were canonically empty. This is incorrect, as we don't actually know the state (having received no information about it), which leads to us being unable to utilize reference.load() which would otherwise allow a user to utilize findBelongsTo/findHasMany to load the relationship manually. While users of references may use reference.reload() instead, we should also firm up our API expectations here, as this is a place wherein we deviate from json-api.

This deprecation would warn when this scenario is encountered. Once the deprecation lifecycle is complete, this deprecation would turn into an assertion, as the relationship is in an invalid state. For additional context, see this bugfix commit that restored this behavior after it was unintentionally broken/discovered: 850bdf2

@runspired
Copy link
Contributor Author

We improved the behavior here slightly by only considering missing relationship data to be empty when no previous information has been received: #5880

Would still love a champion for this deprecation so we can help folks avoid bugs when their payloads are less complete than they should be.

@runspired runspired reopened this Mar 4, 2019
@wagenet
Copy link
Member

wagenet commented Jul 22, 2022

I'm closing this due to inactivity. This doesn't mean that the idea present here is invalid, but that, unfortunately, nobody has taken the effort to spearhead it and bring it to completion. Please feel free to advocate for it if you believe that this is still worth pursuing. Thanks!

@wagenet wagenet closed this as completed Jul 22, 2022
@runspired
Copy link
Contributor Author

This is still pretty important as it's one of our more serious misalignments between spec's and what we do. It's also low hanging fruit :)

@runspired runspired reopened this Jul 22, 2022
@runspired runspired transferred this issue from emberjs/rfcs Sep 1, 2023
@runspired
Copy link
Contributor Author

closing in favor of #7584

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

2 participants