Aliases and Sorting not working in DQL Facets

Issues Dgraph
, , ,
1

Report a Dgraph Bug

Found by @youyin123

PS. Please, dear future engineer working on this. Read the other comments.

What version of Dgraph are you using?

v20.07.1-rc1-15-g1aed0c46

Have you tried reproducing the issue with the latest release?

Master.

What is the hardware spec (RAM, OS)?

N/A

Steps to reproduce the issue (command/config used to run Dgraph).

N/A

Expected behaviour and actual result.

{
  me(func: anyofterms(name, "Alice Bob Charlie")) {
    name
    rated @facets(TEST: rating, orderdesc: rating){ 
      name
    }
  }
}

The response returns "rated|rating" instead of "TEST"

And this query doesn’t work

{
  me(func: anyofterms(name, "Alice Bob Charlie")) {
    name
    rated @facets(TEST: rating) @facets(orderdesc: rating){ 
      name
    }
  }
}
2

@MichelDiz
In the document, I found that it can be sorted by @ faces：

image
image1484Ă—968 84.5 KB

but it doesn’t work in practice：

image
image2258Ă—856 142 KB

Is it because I use it incorrectly? Or can we say that @faces cannot be sorted when it is in datetime format?

3

Scroll down a bit more? You should see the results there. Something like

{
"likes|cd": [
    {"0": "2012-09-06T18:30:38Z"},
    {"1": "2012-08-03T03:52:09Z"}
]
}
4

@chewxy no ,there no result like you said…

{
  "data": {
    "var1": [
      {
        "~hasCreator": [
          {
            "~likes": [
              {
                "like_uid": "0x8ac7187c005d000a",
                "creationDate": "2012-07-12T03:11:27Z",
                "cd": "2012-08-03T03:52:09Z"
              },
              {
                "like_uid": "0x8ac7187c005debca",
                "creationDate": "2012-07-04T00:32:28Z",
                "cd": "2012-09-06T18:30:38Z"
              },
              {
                "like_uid": "0x8ac7187c005ea9d8",
                "creationDate": "2012-03-07T15:08:23Z",
                "cd": "2012-09-08T20:31:53Z"
              },
              {
                "like_uid": "0x8ac7187c005e0fcc",
                "creationDate": "2012-02-07T11:53:10Z",
                "cd": "2012-08-15T11:02:34Z"
              },
              {
                "like_uid": "0x8ac7187c005f991f",
                "creationDate": "2012-01-05T19:27:43Z",
                "cd": "2012-08-24T14:03:39Z"
              },
              {
                "like_uid": "0x8ac7187c005d240d",
                "creationDate": "2011-12-29T14:03:30Z",
                "cd": "2012-08-21T17:39:21Z"
              },
              {
                "like_uid": "0x8ac7187c005ed694",
                "creationDate": "2011-09-05T15:53:42Z",
                "cd": "2012-09-05T03:43:57Z"
              },
              {
                "like_uid": "0x8ac7187c0060585d",
                "creationDate": "2011-08-09T08:52:50Z",
                "cd": "2012-08-13T17:36:38Z"
              },
              {
                "like_uid": "0x8ac7187c005fe8ed",
                "creationDate": "2011-08-08T16:38:00Z",
                "cd": "2012-08-21T12:53:06Z"
              },
              {
                "like_uid": "0x8ac7187c005dbf35",
                "creationDate": "2011-07-15T11:10:44Z",
                "cd": "2012-08-21T08:41:05Z"
              },
              {
                "like_uid": "0x8ac7187c005de6c1",
                "creationDate": "2011-03-16T21:39:19Z",
                "cd": "2012-09-08T15:39:34Z"
              },
              {
                "like_uid": "0x8ac7187c005cdd71",
                "creationDate": "2011-03-15T09:36:59Z",
                "cd": "2012-09-03T02:41:30Z"
              }
            ]
          }
        ]
      }
    ]
  },
  "extensions": {
    "server_latency": {
      "parsing_ns": 120473,
      "processing_ns": 75863135,
      "encoding_ns": 74553,
      "assign_timestamp_ns": 434396,
      "total_ns": 76579962
    },
    "txn": {
      "start_ts": 437402
    },
    "metrics": {
      "num_uids": {
        "": 54,
        "_total": 198,
        "creationDate": 12,
        "dgraph.type": 109,
        "id": 0,
        "uid": 12,
        "~hasCreator": 1,
        "~likes": 10
      }
    }
  }
}
5

This is the “last” structure. We have returned the old one that sets the facet inside the object instead of a list as a map, this response only appears in a list type now. Not sure if Play with Dgraph has updated to the latest.

Your query is wrongly formatted.

It should be like

~likes @facets(cd: creationDate, orderdesc: creationDate)

Any facet param should be inside facets directive. Otherwise, it will sort by the edges found in the nested fields.

6

Okay @youyin123, I think you have found a Bug. I gonna convert this into an issue.

Despite my last reply is logic, the sorting isn’t working with Aliases.

8

@MichelDiz
bug??
no, Your method works!
Thank

image
image2384Ă—1256 314 KB

9

Oh, really? So it was fixed? What is the version you are using?

10

@MichelDiz

  • Dgraph version: v20.07.0.

:blush:

11

Okay, thanks. That’s odd. I have tested on a master build I have and v20.07.1-rc1-15-g1aed0c46. Tomorrow I gonna take a closer look into this.

Thanks again.

Cheers.

12

Just adding some context. @youyin123 Your query isn’t aliased properly. To make both working, use this:

~likes @facets(orderdesc: creationDate, cd: creationDate)

From @MichelDiz’s example:

rated @facets(orderdesc: rating, TEST: rating)

Basically, you have to state the sorting first, then aliases next.

When the order is reversed, it seems any sort statement resets previous aliases unexpectedly.

Moreover, I noticed sort command doesn’t take aliases into account. So, orderdesc: cd and orderdesc: TEST are not correct and won’t render properly, wherever you put those statements (before or after respective aliases).

I’m not working on Dgraph, so these behaviors may (or may not) be intended by developers. By the way, I’m using Dgraph v20.07.1.

P.S. It would be nice for us Dgraph’s users to neglect the order and still manage to render both aliases and sorting flawlessly. Please work on this issue, @MichelDiz and others in the team.

1 Like
13

hi,
@MichelDiz
I encountered a very strange phenomenon.
The following code is OK the last two days, and I also recorded the running time.

image
image2528Ă—1060 369 KB

But today, when I run again, the code reported an error. Why? I want to calculate how long the creationdate in faces is from now.

14

Creationdate is a DateTime type right? So, “Sum” doesn’t support the Datetime type. Only int or float. “min” and “max” supports DateTime tho.

15

@MichelDiz
yes, creationDate is as DateTime type,

actually， is this code error:

math(since(cd))

and I’m pretty sure it could have run before, because I’ve recorded the run time.
so what happend??
I just want to calculate how long the creationdate in faces is from now.

16

Dunno, if you have the ways to reproduce or a video. You can open another issue to track this.

If you do

math(since(message)/(365*24*60*60))

You gonna have how much time has passed since that date until today. In years (in float).

The way you are doing doesn’t make much sense. But, are you trying to compare the time from the node against the facet? That way you should do something like

a1 as math(since(mee)/(365*24*60*60))
a2 as math(since(message)/(365*24*60*60))

test: math(a1 - a2)

That way you have the years from mee and message, and now you can do some other math with it.

17

no no
The error code is

math(since(cd))

not other
do u know why?

18

Humm, is cd variable coming with a well-formatted date type? if so, create another issue to track this specific case.