Global omitempty option

[liron-navon]

Let's say a graphql query accepts an input object, which has an optional string in it, if I use the input object, and not give a value to that string, it should be committed, that's just how graphql works.
Unfortunately, this library doesn't work that way.

Is your feature request related to a problem? Please describe.
I have this input for shopify, the non struct fields are not required

The generation works well, but if In don't include the optional fields, genqlient turns them into null (when defining value as pointer) or to an empty string (when defining value as value).

They should just be omitted as I don't want to send them, otherwise shopify will fail to use this.

Using the "@genqlient(omitempty: true)" is impossible, because the import is required, even tho every field on it is optional.

Describe the solution you'd like
add to the settings.yml file an option "omitempty: boolean" that would just cover all the json fields.

Describe alternatives you've considered
Adding manually the "omitempty" directive, but with thousands of fields it's makes it really hard to use, and time consuming and prone to humen errors.

Additional context
What I get generated, why would an optional pointer to a string not have omit empty?

[benjaminjkraft]

Check out the optional: pointer setting in genqlient.yaml! If I'm understanding your request correctly that's exactly what it does.

[liron-navon]

@benjaminjkraft why did you close it? you don't understand correctly, the "optional: pointer" doesn't omit empty, it passes "null" instead, this breaks different apis, namely "shopify" and "spacex"

[benjaminjkraft]

Thanks for clarifying. I guess it's valid GraphQL to treat explicit null differently. It seems like what you are proposing is a global config to turn on omitempty. That seems reasonable to add, although soon we are going to have to figure out how to make all these related config options not explode the config complexity.

[mujagic-nermin]

Looking at the documentation, I'm trying to achieve what it says here with the global omitempty.

Doesn't seem to be working for my code, even though I followed exactly?

Where is the ,omitempty json tag??? Below is my genqlient.graphql

[dharijanto]

Thanks for clarifying. I guess it's valid GraphQL to treat explicit null differently. It seems like what you are proposing is a global config to turn on omitempty. That seems reasonable to add, although soon we are going to have to figure out how to make all these related config options not explode the config complexity.

Hi Benjamin, just to clarify, I think the author wants the global omitempty: true only for input parameter. He is probably using Hasura 2.0 (just like I am)

Just to give you a bit more background, in Hasura 2.0, they introduced a breaking change that distinguishes "implicit null" vs. "explicit null".

hasura/graphql-engine#7484 (comment)

[dharijanto]

Hi @benjaminjkraft I created a draft PR to fix the issue. Would you mind taking a look?
#264

I haven't written/fixed tests associated to it, I figure I'd check with you first if the direction is okay.

[benjaminjkraft]

Thanks for the context and the PR. I can see why they have ended up wanting the distinction. (For others reading, the changelog entry describes the breaking part of the change, although it sounds like this isn't the only place they draw the distinction.)

I commented in the PR -- for a couple reasons I think a new config option might be useful but I think if we do do that it's a fine way to do things.

At some point we should probably also have a clearer example/FAQ entry for how to use genqlient with hasura, since the hasura-generated schemas seem to have a bunch of quirks that genqlient's defaults don't match with. (But that doesn't have to be now.)

[benjaminjkraft]

One realization I had on the way home: a workaround is to have your inputs be the fields you want to set, rather than the whole object. For example, instead of:

myQuery(myInput: SomeInputType) {
  field(input: $myInput) { ... }
}

you'd do

myQuery(myField: String!) {
  field(input: {myField: $myField}) { ... }
}

Obviously some pluses and minuses there, so it doesn't obviate the issue, but may be useful until we get this option sorted.

[benjaminjkraft]

Ah, I realized while trying to consolidate issues that we also have use_struct_references, which is not quite the same but may also be useful to folks in this issue.

[benjaminjkraft]

Hasura users -- please take a look at #272 and add any thoughts!

[dharijanto]

Hi Ben,

At some point we should probably also have a clearer example/FAQ entry for how to use genqlient with hasura, since the hasura-generated schemas seem to have a bunch of quirks that genqlient's defaults don't match with. (But that doesn't have to be now.)

Yeah I totally agree. Feels a bit non-intuitive at the moment to get genqlient to work with Hasura.

Thanks for responding to the thread and commenting on the PR. Since you've created a separate issue to consolidate Hasura-related discussions, should I just close the PR?

[skandragon]

It is also difficult to use Dgraph because IDs are passed as empty strings, and DGraph rejects this.

Dgraph takes the schema submitted and augments it in various ways, such as:

input AddComponentInput {
  type: String!
  name: String!
  version: String!
  publisher: String
  licenses: [ComponentLicenseRef!]
  purl: String
  cpe: String
  vulnerabilities: [VulnerabilityRef!]
}

type AddComponentPayload {
  component(filter: ComponentFilter, order: ComponentOrder, first: Int, offset: Int): [Component]
  numUids: Int
}

type Mutation {
  addComponent(input: [AddComponentInput!]!): AddComponentPayload
}

The issue I have is I want to set things to "omit empty" on at least some of the fields in this Dgraph-generated type list. I am not sure how to do this. Right now, I can modify the generated Go file, but that is quickly a pain.