Add NullableRelationship support #226
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These changes add the ability to unmarshal links members to links-annotated struct fields. The specification for links members can be found here: https://jsonapi.org/format/#document-links Note that this does not change the existing marshaling behavior of links (the Linkable interface methods), though a fully fleshed out implementation probably should - it's awkward that now interface methods are used to marshal but struct fields for unmarshaling. In other words, an implementation of links marshaling similar to the implementation proposed in PR 58 of the canonical google/jsonapi repository would be most appropriate to pair with these unmarshaling changes. The actual implementation that was accepted is PR 57, utilizing those Linkable/Metable interfaces. From 57: > After looking at both implementations, I think I'd like to vote for this one because it feels flexible, and doesn't add any additional fields to our structs. In general I don't think LINK and META objects really have much to do with the resource objects themselves, they are really more related to the context in which the object is used. This approach keeps structs cleaner. This is subjectively wrong, and assumes that this package is used in the context of a server and not a client. In a client, links members can contain information that is vital to the functionality of the resource itself, so we add that here.
Co-authored-by: Cameron Stitt <[email protected]>
Unmarshal Links type to 'links' annotated struct fields
Allow attributes to be marshalled for relations
Add CI workflow for github actions
Creates a new annotation that invokes special handling for the associated field, assigning exactly one of a selection of models in an intermediate struct. (See README)
polyrelation fields are marshaled as JSON to the first non-nil field within a choice type
Adds test for nil hasOne polyrelation
README badge links
Co-authored-by: Nick Fagerlund <[email protected]>
Introduce nullable types
fix: make Nullable handle significant null marshaling properly
Co-authored-by: Brandon Croft <[email protected]>
add 'source' to error object
Add CODEOWNERS file in .github/CODEOWNERS
…ted-relation fix: handle deprecating relation for polyrelation
Unmarshaling an attribute that is a struct or struct pointer that is decorated with jsonapi tags has historically worked as expected, but, curiously, marshaling did not and required the use of `json` tags instead, making struct reuse difficult for both input and output object attributes. Now, you can specify a struct or struct pointer as an attribute and it will be marshaled into the correct keys. Note that this implemenation does not yet support slices of structs or struct pointers.
Support nested objects within attributes when Marshaling
Update CODEOWNERS, adding Core Cloud team as co-owners
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NOTE: This PR is a copy of hashicorp#23. Since the original owner of the PR is no longer at the company, they are unable to sign the CLA.
http://jsonapi.org/format/#document-resource-object-relationships
http://jsonapi.org/format/#document-resource-object-linkage
Relationships can have a data node set to null (e.g. to disassociate the relationship)
The NullableRelationship type allows this data to be serialized/de-serialized. When serialized, a NullableRelationship with an explicit null will serialize to the appropriate "null" type. Either '"data": null' or '[]'.
Supports slice and regular reference types for serialization, and regular reference types for de-serialization.
The reason to not support slices for de-serialization is we need to decide how to handle the zero type for a NullableRelationship[[]*...] slice. Since we aren't using this and can emulate the nulling behavior by omitting omit-empty we decided to ignore this case for now.