Skip to content
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

Add @export directive to link data between fields/operations #3119

Open
jsimnz opened this issue Oct 7, 2024 · 3 comments
Open

Add @export directive to link data between fields/operations #3119

jsimnz opened this issue Oct 7, 2024 · 3 comments
Labels
feature New feature or request

Comments

@jsimnz
Copy link
Member

jsimnz commented Oct 7, 2024

Add a @export directive to query fields that dynamically populates a defined variable. This would allow field values from one query/mutation to be used within another. For now, this should be scoped to a single mutation or query block, but we can add suport for multiple/interleaves mutation and query blocks in the future. Discussion

Example

mutation($dogID: String) {
  create_Dog(input: {name: "Fido"}) {
    _docID @export(as: "dogID")
  }
  update_User(docID:"123", input: {dog: $dogID}) {
    name
    dog
  }
}

Here we are defining a variable at the top of the mutation dogID: String which will have the resulting value from the @export directive from the _docID @export(as: "dogID").

Design

We will need to detect the type of the variable (strongly typed) and make sure:

  1. The output type of the field with the @export directive matches the variable type
  2. If the exported field is contained within a List type (since create_Dog outputs a [Dog] type) then
    A) The variable can be a single (non list) type but the output result type can only contain a single value. In other words, the @export directive can only be called once
    B) Otherwise, the variable must be a list type as well.

Rough outline of the implementation (from here)

  1. Define a new directive
  2. Specify a serial execution dependency order (should this match the provided order of the ops by the user? Or should it be smarter and recognize which ops output data and which ops depend on data?)
  3. Add a validation rule to validate that fields with @export directives defined on the query refer to defined variables within the query, and that the field type is a compatible scalar type (or list-scalar type) with the variable type (see point (2 A/B) above)
  4. Add a planNode (or update an existing node (eg selectNode)

Note: The value of the @export field should overwrite any existing manually provided variable value

References

@jsimnz jsimnz added the feature New feature or request label Oct 7, 2024
@islamaliev
Copy link
Contributor

I didn't thoroughly read the specs, but do we really need to pass $dogID as a variable to the mutation? Feels artificial. Why not to write like this:

mutation {
  create_Dog(input: {name: "Fido"}) {
    _docID @export(as: "dogID")
  }
  update_User(docID:"123", input: {dog: $dogID}) {
    name
    dog
  }
}

@fredcarle
Copy link
Collaborator

@islamaliev I believe that variable need to be defined and typed.

@jsimnz
Copy link
Member Author

jsimnz commented Oct 12, 2024

Fred is correct here, we could in theory support "implicit" variables in addition to explicit ones, so the more sensitive gql clients work, but that somewhat just complicates things

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants