Support value variables for paging params (offset, after, first)

Moved from GitHub dgraph/2564

Posted by disconsented:


 var(func: eq(account, "100")){
       cid as uid  
   msg as message_limit
 messageCount(func: uid(cid)){
   messages(orderdesc: timestamp, offset: val(msg)){

message_limit here is message_limit:int . .
The essential point is that I want to be able to set values in the database to use as limits application side. The above results in : strconv.ParseInt: parsing "msg": invalid syntax which seems inconsistent considering that variables can be used for ordering as suggested by the documentation.

danielmai commented :

Using val() with offset sounds like a valid feature.

Took another look at your specific use case. You’d like to do message limiting, so would it be better to use first: to retrieve only N messages? Instead of offset, which skips the first N messages and returns the rest.

MichelDiz commented :

I think this feature could be very handy e.g:

#dummy query as empty query you can't use, other than aggregation.
  var(func: uid(0x1)){  
    amount as math(5)
    page   as math(2)
    OST as math(amount * page)
  q(func: has(somePred), 
    orderasc: otherPred, first: val(amount), offset: val(OST) ) {

romshark commented :

I think I faced a similar problem working on my dgraph tech-demo. I’m trying to implement pagination and this is the query I assumed to work:

query PostsPage(
  $first: int = 4,
  $id: string = "ce9f834c2fd143e7a0994cd01564d990"
) {
  var(func: eq(, $id)) {
    p as uid
    func: has(,
    after: val(p),
    first: $first
  ) {

Unfortunately, it seems like I can’t use p as an argument for after:

": strconv.ParseUint: parsing \"p\": invalid syntax"

I suddenly need 2 roundtrips to get the job done:

  • fetch the uid by id
  • then fetch the page using the uid

This is obviously bad because it could have been done with just a single simple query.
Please correct me if I’m wrong.

paulrostorp commented :

@romshark 's use case is the same as ours. It’s a big issue that we can’t do this…
I am surprised this feature isn’t already implemented…

MichelDiz commented :

@paulrostorp romshark 's case is different. He is using GraphQL Variables (a concept imported from GraphQL). You can open another ticket for this, cuz this implementation is totally different. But please, first check if there isn’t any other issue already on this topic.

Unless the case is a mix of both features. And the GraphQL Variables works fine on this case. I remember someone working on something related to GQL Vars a year ago, not sure.


paulrostorp commented :

@MichelDiz You are right, our use case is not graphql, however it is similar to @romshark because we also use an identifier that is not the uid, therefore we’d need to be able to use val() in “after” in order to avoid doing two roundtrip queries. What I’m looking to do is something like this:

var(func: eq(someItem.xid, "someXid")) {
someItem as uid

items(func: ... , after: val(someItem)) {

MichelDiz commented :

Okay, so this ticket is for your case too. I have asked @lgalatin to take a look at this ticket and manage what to do.

Is there a way to track the advance of this ?

You can click below where it says normal to say watching.

1 Like