Predicate names in the /state endpoint prefixed with 0-

As a follow-up on Predicate names in the /state endpoint contain NULL characters, where v21.03.x added NULL-characters to the predicate field in the /state endpoint response, v21.09.x now adds ‘0-’ (seen in v21.09.0-rc2).

Edit: As pointed out in the answers, this is related to namespaces. With that, my question boils down to: "predicate" feels like it should be the exact term as in the schema of a namespace. It should not be prefixed. The tablet id and namespace id should be provided in separate fields.

This is the relevant JSON response from the /state endpoint:

{
  "groups": {
    "1": { … }
  },
  "tablets": {
    "0-dgraph.drop.op": {
      "groupId":1,
      "predicate":"0-dgraph.drop.op",
      …
    },
    "0-dgraph.graphql.p_query": {
      "groupId":1,
      "predicate": "0-dgraph.graphql.p_query",
      …
    },
  },
…  
}

What I would expect is a response like this:

{
  "groups": {
    "1": { … }
  },
  "tablets": {
    "0-dgraph.drop.op": {
      "id":"0-dgraph.drop.op",
      "groupId":1,
      "namespace":0,
      "predicate":"dgraph.drop.op",
      …
    },
    "0-dgraph.graphql.p_query": {
      "id":"0-dgraph.graphql.p_query",
      "groupId":1,
      "namespace":0,
      "predicate": "dgraph.graphql.p_query",
      …
    },
  },
…  
}

This way, namespace id becomes explicit and does not require any obscure string processing:

  • The key and "id" of a tablet is OK to be opaque: do not make any assumption on its structure or contained information.
  • The "predicate" should match what you see in the response of schema { predicate } given a namespace.
  • The "namespace" provides the namespace id explicitly and as a JSON integer.

The 0 you see is the namespace. New feature in v21.x

When you see a bunch of null characters in the logs or state endpoint is is because the namespace is actually a 64bit integer, and that is the full binary representation, with the least significant bit being the one that would change for namespace 1, etc.

Edit: Sorry this part was already answered for you on the other linked thread. That’s what I get for half reading the question.

@iluminae thanks for the response. After looking into multi-tenancy and namespaces I figured out the concepts behind this change. I have refocused my question above. It boils down to proposing a better JSON response for the /state endpoint. With the current response, clients would be required to parse string values that should be considered opaque.

1 Like

Yea, I like it and totally agree :+1:

1 Like