Arguments on custom fields

Issues GraphQL
, ,
#1

Hi,

Since graphql: Allow user to define and pass arguments to fields. by pawanrawal · Pull Request #5562 · dgraph-io/dgraph · GitHub was merged back in June, I was under the impression that arguments to custom fields were supported in master. So I ran dgraph/dgraph:master from Docker Hub and tried to add the following GraphQL schema:

type TSVal @remote {
    timestamp: String! @id
    value: Int
}
 
type Timeseries {
    id: String! @id
    values(from: DateTime!, till: DateTime!): [TSVal] @custom(http: {
        url: "http://localhost:5000/timeseries?from=$from&till=$till"
        method: GET
    })
}

I got the following error message:

{"errors":[{"message":"resolving updateGQLSchema failed because input:9: Type Timeseries; Field values; url query inside @custom directive uses a field from that is not defined.\ninput:9: Type Timeseries; Field values; url query inside @custom directive uses a field till that is not defined.\n (Locations: [{Line: 3, Column: 4}])","extensions":{"code":"Error"}}]}

So my question is: Is this change supposed to be in the Docker container? Am I using this wrong?

Best regards,
Marcus

#2

If I add a custom query, it works as expected:

type Query {
    customTS(id: String!, from: DateTime, till: DateTime): [TSVal] @custom(http: {
        url: "http://localhost:5000/timeseries?from=$from&till=$till"
        method: GET
    }) 
}
1 Like
#3

Hi @stormking, I believe what you are doing wrong is with adding arguments to value and using it with the URL. Currently, to resolve params in URL dgraph uses fields in the type. You can read more about that here.

Its actually in our roadmap to add arguments in custom fields.

So having the schema like this will work

type TSVal @remote {
    timestamp: String! @id
    value: Int
}
 
type Timeseries {
    id: String! @id
    from: DateTime!
    till: DateTime!
    values: [TSVal] @custom(http: {
        url: "http://localhost:5000/timeseries?from=$from&till=$till"
        method: GET
    })
}

can you please help with your use case so that we can help you with the solution.

#4

Hi Aman,

I know it’s on the roadmap, I just thought the commit I referenced in my initial post meant that it was already available in master. Seems I was wrong, there. Any idea when that feature will be available?

Thanks for the workaround, I came up with pretty much the same thing in the meantime, but for my usecase, the custom query is more suitable.

Thanks again, and keep up the good work! In the past, I dealt with JanusGraph and Cassandra and in comparison, Dgraph is just amazing!

Best regard,
Marcus

1 Like
#5

Oh, and my usecase is to link Dgraph with InfluxDB to have an universal datastore. Structured data will be held in the graph, timeseries mass-data will be forwarded to Influx. So I really need to specify “from” and “till” dynamically in my queries.

Ideally, I would query data like this:

query {
  getMachine(machineID: "someIdentifier") {
    timeseries {
      values(from: "2020-10-07T18:00:00Z", till: "2020-10-07T18:30:00Z") {
        timestamp
        value
      }
    }
  }
}

And then get the data for all timeseries linked to the “Machine” vertex for the requested timeframe.

For now, I will workaround the issue by splitting the query, getting the Timeseries’ id first and then using the custom query to get the data for the requested timeframe.

#6

Hi @stormking, your use case looks really exciting. We would love to learn more about your journey of integrating Influxdb with Dgraph.

@pawan do we have any timeline for this?

#7

Hi Aman,

Any news on this issue?

#8

It would be really great to know if you at least consider this. You’ve already updated your schema parser to allow that kind of definition. Now all you have to do is to pass these arguments to the REST or GraphQL call that is made. The hard part is already done! It would make @remote types so much more powerful!

I really don’t understand why there is so much silence in such a no-brainer!

Best regards,
Marcus

#9

Hi @stormking,

Really sorry that we missed this.
We will surely consider this, and plan to have it as part of the 21.07 release.

Thanks

#10

Hi abhimanyusinghgaur,

Thanks for your feedback. I hope you acknowledge that getting no feedback at all is worse than getting a “no”. So thanks you for your answer and I really hope this gets implemented. Currently, I’m betting my career on Dgraph because I see the potential and you should see that, too! The support of “remote types” is a major competetive factor, if you expand on that Unique Selling Point, you will certainly succeed as a company!

Best regards,
Marcus

#11

@hardik please track this.

Sorry for the silence here. That’s not the kind of experience we want to create for our users.