Using expand(_all_) doesn't work for uid(query_variable) functions

On my stored data I have tried the following query variable query:

{
 var(func: has(sector_t)) @filter(anyofterms(name, "Music")) {
    ~sector {
      musiccomp as ~industries @filter(has(company_t))
    }
  }

  q(func: uid(musiccomp)) {
    name
    short_name
    description
    date_created
    date_modified
    uris
    stocks {
      exchange {
        name
      }
      closing_prices {
        on
        dated_float
      }
    }
  }
}

And this seems to return the expected result (of a list of companies with correct values in ‘name’, ‘description’, ‘stock’, etc.) but if I instead do a very similar query with expand(_all_) instead of manually specifying the predicates I get an empty result back.

{
 var(func: has(sector_t)) @filter(anyofterms(name, "Music")) {
    ~sector {
      musiccomp as ~industries @filter(has(company_t))
    }
  }

  q(func: uid(musiccomp)) {
   expand(_all_) {
     expand(_all_)
   }
  }
}

Is this expected? If so, is there a workaround to be able to use expand(_all_) with query variables and func: uid(query_variable) type queries?

It gets even stranger… All scalar predicates don’t seem to be listed when I query _predicate_ (only UID predicates a listed) for a node like this:

{
  preds(func: anyofterms(name, "Acme")) {
  _predicate_
}
}

returns this:

{
  "extensions": {
    "server_latency": {
      "encoding_ns": 966700
    },
    "txn": {
      "start_ts": 20123
    }
  },
  "data": {
    "preds": [
      {
        "_predicate_": "industries"
      }
    ]
  }
}

It should have a lot more predicates listed since I can do this and it works fine:

{
  preds(func: anyofterms(name, "Acme")) {
    name
    short_name
    uris
    stocks {
      ticker
    }
    industries {
      name
    }
}
}

returns this:

{
  "extensions": {
    "server_latency": {
      "encoding_ns": 997900
    },
    "txn": {
      "start_ts": 20144
    }
  },
  "data": {
    "preds": [
      {
        "name": "Acme Corporation",
        "short_name": "Acme",
        "uris": [
          "www.acmecorp.com"
        ],
        "stocks": [
          {
            "ticker": "ACME"
          }
        ],
        "industries": [
          {
            "name": "Roadrunner Traps & Accesories"
          }
        ]
      }
    ]
  }
}

I have attached the schema and dummy data I used to populate this db.bug_report.zip (1.8 KB)

Hi Akanakia, Which version are you running?

if it’s an old version try

dgraph --version

Or start Alpha node and look for the logs, there is a “stamp” with the version on it.

Checked alpha. Version is: v1.0.13

Well, I’ve tested your dummy data (thank your for that, It’s very important dummies in hand) and I had no issues using v1.0.14 - I gonna test it in v1.0.13 tho. BTW you have 3 levels of data relation, you need to add expands* for each level.

Also, instead of use has at root, try to always query by anyofterms and filter by “has”. It’s better IMHO.

Dgraph version   : v1.0.14
Commit SHA-1     : 26cb2f94
Commit timestamp : 2019-04-12 13:21:56 -0700
Branch           : HEAD
Go version       : go1.11.5
{
  preds(func: anyofterms(name, "Acme")) {
  _predicate_
}
}
{
  "data": {
    "preds": [
      {
        "_predicate_": [
          "industries",
          "name",
          "company_t",
          "date_created",
          "uris",
          "short_name",
          "date_modified",
          "stocks"
        ],
        "uid": "0x2728"
      }
    ]
  }
}

First Query

{
  "data": {
    "q": [
      {
        "name": "Kazooie LLC",
        "date_created": "2019-04-23T22:08:14.743877Z",
        "date_modified": "2019-04-23T22:08:14.743877Z",
        "uris": [
          "www.wikipedia.com/wiki/kazooie"
        ],
        "stocks": [
          {
            "exchange": [
              {
                "name": "Nasdaq",
                "uid": "0x2717"
              }
            ],
            "closing_prices": [
              {
                "on": "2019-04-23T00:00:00Z",
                "dated_float": 15.87,
                "uid": "0x2716"
              },
              {
                "on": "2019-04-19T00:00:00Z",
                "dated_float": 25.84,
                "uid": "0x2719"
              },
              {
                "on": "2019-04-21T00:00:00Z",
                "dated_float": 24.35,
                "uid": "0x271e"
              },
              {
                "on": "2019-04-20T00:00:00Z",
                "dated_float": 25.01,
                "uid": "0x2722"
              },
              {
                "on": "2019-04-22T00:00:00Z",
                "dated_float": 25.55,
                "uid": "0x272b"
              }
            ],
            "uid": "0x271d"
          }
        ],
        "uid": "0x271c"
      },
      {
        "name": "Banjo Incorporated",
        "short_name": "Banjo Inc.",
        "date_created": "2019-04-23T22:08:14.743877Z",
        "date_modified": "2019-04-23T22:08:14.743877Z",
        "uris": [
          "www.banjo.com"
        ],
        "stocks": [
          {
            "exchange": [
              {
                "name": "Nasdaq",
                "uid": "0x2717"
              }
            ],
            "closing_prices": [
              {
                "on": "2019-04-22T00:00:00Z",
                "dated_float": 22.45,
                "uid": "0x2711"
              },
              {
                "on": "2019-04-20T00:00:00Z",
                "dated_float": 19.17,
                "uid": "0x2715"
              },
              {
                "on": "2019-04-21T00:00:00Z",
                "dated_float": 19.9,
                "uid": "0x2718"
              },
              {
                "on": "2019-04-23T00:00:00Z",
                "dated_float": 21.4,
                "uid": "0x2721"
              },
              {
                "on": "2019-04-19T00:00:00Z",
                "dated_float": 19.58,
                "uid": "0x2727"
              }
            ],
            "uid": "0x272a"
          }
        ],
        "uid": "0x2725"
      }
    ]
  }
}

Last one

{
  "data": {
    "q": [
      {
        "uris": [
          "www.wikipedia.com/wiki/kazooie"
        ],
        "date_modified": "2019-04-23T22:08:14.743877Z",
        "stocks": [
          {
            "ticker": "KZO",
            "ipo_year": "1989-01-01T00:00:00Z",
            "dividend": 0,
            "stock_t": ""
          }
        ],
        "industries": [
          {
            "name": "Musical Instruments",
            "industry_t": ""
          }
        ],
        "name": "Kazooie LLC",
        "company_t": "",
        "date_created": "2019-04-23T22:08:14.743877Z"
      },
      {
        "uris": [
          "www.banjo.com"
        ],
        "date_modified": "2019-04-23T22:08:14.743877Z",
        "stocks": [
          {
            "ticker": "BJO",
            "ipo_year": "1998-01-01T00:00:00Z",
            "dividend": 0,
            "stock_t": ""
          }
        ],
        "short_name": "Banjo Inc.",
        "industries": [
          {
            "name": "Musical Instruments",
            "industry_t": ""
          }
        ],
        "name": "Banjo Incorporated",
        "company_t": "",
        "date_created": "2019-04-23T22:08:14.743877Z"
      }
    ]
  }
}

Also tested on:

Dgraph version   : v1.0.13
Commit SHA-1     : 691b3b35
Commit timestamp : 2019-03-09 19:33:59 -0800
Branch           : HEAD
Go version       : go1.11.5

No erros found.

I think the reason is related to something in the operating system. I noticed you are using Windows. Dgraph is more familiar with Unix systems. However I would recommend you try to use the flag --cwd to set the main path.

PS, sorry, this flag exists only on master - I forgot that.

e.g:

dgraph zero --cwd c:\data\dgraph\zero
dgraph alpha --cwd c:\data\dgraph\alpha -l 2048

Well, as the --cwd isn’t available. In your case, take dgraph.exe to the path c:\data\dgraph\alpha and start Dgraph from there.

no need to set p or w in this case.

Let me know if it works for you.

Cheers.

Thanks for the response. Just tried with dgraph 1.0.14. It seems that if I move everything into the same directory as you suggested then it works but if the dgraph, dgraph-ratel executables are in a different directory than the data then the same problem as I originally posted occurs. This would seem to indicate that there may be a bug when implementing the -p and -w flags in dgraph alpha. Will open an issue on github with the repro steps from this thread. Also, I noticed that there is a /zw folder created as well when launching dgraph alpha. Could this be happening because the /p, /w and /zw folders are all expected to be in the same root? I’m just trying to understand this strange behavior with the db.

Ratel is just a server for the UI. There’s no need for data or something. So it can be anywhere.

Hum, this should be related to Windows only. This issue does not exist in other OS. I can test this soon in Windows. However this issue does not seem important because if you intend to create Bare-metal the recommended is to use Linux or linux containers. Windows only for testing. And it’s complicated to keep compatible binaries between diff systems. However I will test this and I can even open an issue for this or other issue if I found one.

I see, well “zw” is from Zero node. You are starting both Zero and Alpha on the same path. So, create two folders, copy dgraph.exe to each folder, and then start Dgraph in each folder with a node type, respectively. But in fact this is not even so important. It would matter if you had created several Alphas and several Zeros. They would conflict with the same folder.

Well, explain in details what you’re doing. Without context there is no way I can help much.

I want to know how can i deploy dgraph in docker to get full predicate of expand(all). When i deploy zero、alpha in different containers, i only get “industry” predicate. But when i deploy zero in one container, then deploy alpha in this container, i can get all perdicates using expand(all). Can you tell me how can i get all predicates when i use docker and have many alpha nodes?

I’m not sure what you doing and Why this is happening. If you followed strictly to docs you should be good.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.