From 737eeed85b954a2b43445e3bca2c7ee938685500 Mon Sep 17 00:00:00 2001 From: Jorge Olivero Date: Fri, 6 Mar 2020 18:59:41 -0600 Subject: [PATCH] rfcs: Making subgraph composition imports static --- ...006-subgraph-composition-static-imports.md | 89 +++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 rfcs/0006-subgraph-composition-static-imports.md diff --git a/rfcs/0006-subgraph-composition-static-imports.md b/rfcs/0006-subgraph-composition-static-imports.md new file mode 100644 index 0000000..ebf51e5 --- /dev/null +++ b/rfcs/0006-subgraph-composition-static-imports.md @@ -0,0 +1,89 @@ +# RFC-0004: Fulltext Search + +
+
Author
+
Jorge Olivero
+ +
RFC pull request
+ +
Obsoletes (if applicable)
+
-
+ +
Date of submission
+
2020-03-06
+ +
Date of approval
+
2020-03-06
+ +
Approved by
+
+
+ +## Contents + + + +## Summary + +Initial designs of subgraph composition allowed imports to be linked dynamically +at query time when schemas are imported by subgraph name. This setup makes it +difficult to provide a reliable experience to end users who are querying because +it provides no guarantees that the dynamically linked subgraphs are deployed and +fully indexed. To address this, schema imports should be static. + +## Goals & Motivation + +Finish and deploy subgraph composition. + +## Urgency + +- + +## Detailed Design + +The `graph-cli` and `graph-node` components need to be updated. + +### graph-cli + +1. Resolve all imports by name to the latest subgraph version hash leveraging a + new rpc method on the graph-node when the `graph dep update` (?) command is run +2. Incorporate the subgraph version hashes from the previous task into one of + these options: + - A new yaml document mapping `SubgraphName` -> `SubgraphId` + - A new yaml field on the existing manifest document mapping `SubgraphName` -> + `SubgraphId` + - Rewrite the existing graphql schema and replace all `@import( from: { name: + "ethereum/mainnet" } )` with `@import( from: { id: "Qm...", name: + "ethereum/mainnet" } )` + +### graph-node + +1. Add json rpc method to resolve a set of subgraph names to their latest hash + version +2. Depending on how locked dependencies are incorporated into the + subgraph_deploy command + - If a separate hash is provided in the deploy command for the locked + dependencies: + 1. Resolve the hash + 2. Save the locked dependencies into a new/existing relation + 3. Incorporate the locked dependencies into SubgraphManifest validation + - If the locked dependencies are a new mapping on the manifest then: + 1. Ensure the new properties on the manifest are saved correctly + 2. Incorporate the locked dependencies into the SubgraphManifest validation + - If the locked dependencies are just a part of the GraphQL input schema + definition: + 1. Incorporate locked dependencies into the SubgraphManifest validation +3. Remove the use of `SchemaReference::ByName` in the subgraph manifest +validation code and the store schema cache +4. Remove the concept of unstable imports in the schema cache + +## Compatibility + +This proposal does not change any existing interfaces, so no migrations +will be necessary for existing subgraph deployments. + +## Drawbacks and Risks + +## Alternatives + +## Open Questions