Add a typed link node to allow traversal with code gen'd builders across links#41
Add a typed link node to allow traversal with code gen'd builders across links#41hannahhoward merged 3 commits intomasterfrom
Conversation
Add the concept of a suggested node builder to links that are a reference to a specific typed node that has a code-gen'd node builder
Codecov Report
@@ Coverage Diff @@
## master #41 +/- ##
==========================================
+ Coverage 72.21% 72.24% +0.04%
==========================================
Files 50 50
Lines 3162 3173 +11
==========================================
+ Hits 2283 2292 +9
- Misses 789 790 +1
- Partials 90 91 +1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Yeah, this looks about right. Cool, thanks.
One minor comment that I think might be a typo of sorts, but otherwise I'd say go ahead and merge it.
I also tried to game it out putting the new method on the Link interface, but agree, it came out weird. It's correct that what kind of node to build may depend on what kind of structure we're already building (e.g., using codegen types vs not) and so it makes sense for this feature to be on the Node moreso than the Link.
I wonder what this will look like after NodeStyle from the research branch is introduced -- I bet this method might jump over to that type. And in doing so, might be able to remove the typed package from dependencies of traversal again, which seems like it might be a good thing. But that's a thing to sort out later; might as well merge this now.
schema/gen/go/genKindLinkNode.go
Outdated
| `, w, gk) | ||
| } | ||
|
|
||
| func (gk generateKindLink) EmitTypedLinkNodeMethodReferencedLinkBuilder(w io.Writer) { |
There was a problem hiding this comment.
s/ReferencedLinkBuilder/ReferencedNodeBuilder/ ?
There was a problem hiding this comment.
awesome, done, and then I'm gonna merge
rename EmitTypedLinkNodeMethodReferencedLinkBuilder to EmitTypedLinkNodeMethodReferencedNodeBuilder
Goals
Mostly, I want to support fast Graphsync :)
But concretely, when performing a traversal, if my schema contains a hint about what the node on the other side of the link is, and I have a custom builder for that type, I should utilize that information to determine what node builder to use in NodeBuilderChooser.
This also unlocks a lot of customization of NodeBuilderChooser without having to modify the default function.
There will still need to be some graphsync work to handle starting with the right root node builder, but this feels like it would unlock a lot of behaviors for code-gen
For Discussion
I explored putting this method on the generated link itself. This turned out to have several problems -- specifically, links vary according to how they reference their data and how they load that data. Currently, the only link type is CIDs. It turned out to not be able to continue supporting an abstract link type and a concrete CID link type while also varying a link type according to where it is typed.