-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
implement new conventions for IDable objects (#5881)
* implement new conventions for IDable objects This is an assorted set of sweeping changes that fix the longstanding bug involved with traversing lists of ID-able objects in the SDK. We've worked around this issue about 10 times in the past two weeks, and now I understand why! In short, we need a reliable way to go from foos: [Foo!]!, to selecting the Nth Foo, and querying against it. In Go this looks like the following, which actually panics prior to this commit: funs, _ := mod.Functions(ctx) for _, fun := range funs { fun.Name(ctx) // BOOM } This was panicking because the implementation for returning lists of objects only dealt with scalars, leaving the rest of the object "hollow" (nil q or c fields). It could have populated c, but q was impossible: how do you chain queries from the Nth element in a list? If you had a list of ID-able objects you could at least query them by ID and chain from there, but how do you know how to query by ID? This commit adds a new rule: all ID-able objects implement a top-level `loadFooFromID(id: FooID!): Foo!` resolver. That means when an SDK sees a list of [Foo!]! objects, it knows it can just fetch IDs and then create objects that query from loadFooFromID(id: $id). This new rule is leveraged by a new `core/schema/` helper for registering resolvers that follow this pattern, to help cut down on a ton of boilerplate. (I think more code can be deleted than what's in this commit, may look after.) Now that there's a dedicated constructor for this, we can start removing the optional ID arg from other constructors, which also means that ID-able objects can now be constructed with required args. I applied this change to GeneratedCode, Module, and Function, and deprecated the id args everywhere else. Along the way, I had to rename CacheID to CacheVolumeID. This has long been a thorn in every SDK developer's side, since it's the _only ID type_ that doesn't match its corresponding object type. We're about to make breaking changes for Services v2 so I figure this is worth doing now. Also, bumps graphql-go-tools to a version that doesn't just swallow schema errors and result in cryptic second-order runtime errors. Signed-off-by: Alex Suraci <[email protected]> * sdk/rust: remove CacheVolumeID special-case, regen Signed-off-by: Alex Suraci <[email protected]> * regen node, python Signed-off-by: Alex Suraci <[email protected]> * python: remove noqa now that deprecations are back Signed-off-by: Alex Suraci <[email protected]> * sdk/go: refactor away high-maintenance type maps * One was of all custom scalars (IDs + Platform + JSON) and was ultimately used to detect enums during marshaling. This is now handled using an interface instead that all enum values conform to. * The other was, and had to be, only IDs. This was used for detecting if FooID! types should be converted to object counterparts. Now we just rely on type names always being Type+"ID", which we can do now that they're all consistent. Signed-off-by: Alex Suraci <[email protected]> * re-bootstrap go sdk Signed-off-by: Alex Suraci <[email protected]> * add changie Signed-off-by: Alex Suraci <[email protected]> * fix up deprecation syntax + typeDef doc Signed-off-by: Alex Suraci <[email protected]> * regen SDKs Signed-off-by: Alex Suraci <[email protected]> * add missing doc + regen Signed-off-by: Alex Suraci <[email protected]> --------- Signed-off-by: Alex Suraci <[email protected]>
- Loading branch information
Showing
17 changed files
with
580 additions
and
351 deletions.
There are no files selected for viewing
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
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
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
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
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
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
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
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
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
Oops, something went wrong.