-
-
Notifications
You must be signed in to change notification settings - Fork 60
nested record duplicates #359
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
Conversation
This ensures that: includes include_a: [include_a: [:include_a]] is the same as includes include_a: [include_a: []] It was already the case but this makes it explicit.
|
Yeah, I think the fix won't be able to be using Could you pare this down just to a failing test? We can then explore solutions. |
|
Should we write more tests ? |
|
It looks like the feature you're working on got added in? Main thing we want to start w/ is a test that fails proving the issue, and then we can explore what the cause is and how to avoid the issue w/o using |
|
Ooops. I probably rebased the branch, then forgot, then pushed the revert... |
|
I messed it up, sorry. I close this PR and open a clean one. |
Here is a commit about the missing linkage data. Turns out it's not related to my json_api_resources-like always_include_linkage implementation. It also happens when including deep nested relations.
I'm not sure about the fix though. It seems straightforward, but I wonder if it could lead to other side-effect problems, like different include paths producing multiple versions of the same record, with different preloaded data.
Also, I'm not sure if Enum.uniq is the way to go, or if it would be better to dedup on type + id only.
Contributor checklist
Leave anything that you believe does not apply unchecked.