-
-
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
[DEPRECATION] missing data for sync
relationships should not be considered empty
#8816
Comments
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. |
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! |
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 :) |
closing in favor of #7584 |
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 utilizefindBelongsTo
/findHasMany
to load the relationship manually. While users of references may usereference.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
The text was updated successfully, but these errors were encountered: