Can't delete : Please use * with delete operation for non-list type: [_predicate_]

Users
1

Hi,

We are testing DGraph as new technology to store & explore our business data.

We are stuck because we can’t delete nodes literal values.

Here are the step to reproduce the issue :

We use Kubernetes (through microk8s) and install DGraph as following :

kubectl create -f https://raw.githubusercontent.com/dgraph-io/dgraph/master/contrib/config/kubernetes/dgraph-single.yaml

The version of Ratel is :
Built at 2019-04-01T20:12:42.329Z
Commit: c30e6f0
Commit Info: c30e6f0 Fri Mar 22 18:44:20 2019 +0200 (HEAD -> master)

We use following schema :

<xid>: int @index(int) @upsert .
<name>: string @index(hash, trigram) .
<type>: string @index(hash) .
<referent>: string .
<referents>: uid @reverse .

We insert following datas :

{
 set {
    _:class <referents> _:r1 .
    _:r1 <referent> "" .
    _:r1 <name> "Referent1" .
    _:r1 <type> "Referent" .
    _:r1 <xid> "1" .
    _:class <referents> _:r2 .
    _:r2 <referent> "" .
    _:r2 <name> "Referent2" .
    _:r2 <type> "Referent" .
    _:r2 <xid> "2" .   
    }
}

We can query on datas created :

{
  node(func: uid(0x2711)) {
    uid
    name
    type
    xid
  }
}

{
  "extensions": {
    "server_latency": {
      "parsing_ns": 4532,
      "processing_ns": 6298463,
      "encoding_ns": 409192
    },
    "txn": {
      "start_ts": 418482
    }
  },
  "data": {
    "node": [
      {
        "uid": "0x2711",
        "name": "Referent1",
        "type": "Referent",
        "xid": 1
      }
    ]
  }
}

We can delete links between referent and <referents>

{
 delete {
   <0x2713> <referents> <0x2711> .
   <0x2713> <referents> <0x2712> .
  }
}

{
  "data": {
    "code": "Success",
    "message": "Done",
    "uids": {}
  },
  "extensions": {
    "server_latency": {
      "parsing_ns": 6117,
      "processing_ns": 23014792
    },
    "txn": {
      "start_ts": 420585,
      "commit_ts": 420586,
      "preds": [
        "1-referents"
      ]
    }
  }
}

But we can’t remove referent nodes <0x2711> & <0x2712>, nor delete their predicates (referent, name, type & xid)

We try following formats :

{
 delete {
   <0x2711> * * .
    }
}

{
 "delete": [
    { "uid": "0x2711" }
  ]
}

{
 delete {
   <0x2711> <name> * .
    }
}

{
 "delete": [
    { "uid": "0x2711", "name": null }
  ]
}

We have following error :

{
  "errors": [
    {
      "code": "ErrorInvalidRequest",
      "message": "Please use * with delete operation for non-list type: [_predicate_]"
    }
  ],
  "data": null
}

We try other format :

{
delete {
  <0x2711> <name> "" .
   }
}

We have following error :

{
  "errors": [
    {
      "code": "ErrorInvalidRequest",
      "message": "Please use * with delete operation for non-list type: [name]"
    }
  ],
  "data": null
}

What is wrong in our process?

Delete a node & a predicate is a requirement to adopt DGraph.

2

Nothing is wrong as far I can see. But not sure what is happening. Can you get into the pod and check what is the Dgraph version running? So I can test on my side.

3

Thanks for the answer!
Versions for ALPHA & ZERO :
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

4

Okay, I’ve just tested on v1.0.12 and v1.0.13 but can’t reproduce it.
Are you sure these predicates are not using list type? or @Lang?

In my tests following what you did I did not get any error. I’ve tested 4 versions.
All of them were successful.

5

The last error is not really an error. You are supposed to delete literal values using the notation <uid> <predicate> *.

However, the other message you saw seems like a bug indeed. _predicate_ is an internal predicate used for expand queries. You are the second person that has reported this issue but so far we have not been able to replicate it. I’ll look into it again.

For now, if this error presists, you can get around it by starting a new clean cluster with the alphas with the flag --expand_edge set to false. Note that queries using the expand keyword won’t be supported but everything else should work.

6

If you are still seeing this issue, can you past here the output of running the following query?

schema {}

7

I looked into this issue and while I haven’t gotten to the root cause, it seems like the _predicate_ predicate goes from having type [string] to having type string (i.e from being a list to being a literal).

In the short term, if you get into that situation again, the dirty fix is to send a schema update to restore this predicate to a list. The update you would need to send is:

_predicate_: [string] .

In the long term, we are planning to get rid of _predicate_ altogether starting with version 1.1. It’s expensive to maintain and prone to errors as it’s not transactionally sound (updates to this predicate do not go through the consensus protocol the rest of the updates do).

1 Like
8

Thanks a lot for your answers!

Here is our current schema :

{
  "extensions": {
    "server_latency": {
      "parsing_ns": 115,
      "processing_ns": 338
    },
    "txn": {
      "start_ts": 683821
    }
  },
  "data": {
    "schema": [
      {
        "predicate": "_predicate_",
        "type": "default"
      },
      {
        "predicate": "name",
        "type": "string",
        "index": true,
        "tokenizer": [
          "hash",
          "trigram"
        ]
      },
      {
        "predicate": "referent",
        "type": "string"
      },
      {
        "predicate": "referents",
        "type": "uid"
      },
      {
        "predicate": "type",
        "type": "string",
        "index": true,
        "tokenizer": [
          "hash"
        ]
      },
      {
        "predicate": "xid",
        "type": "int",
        "index": true,
        "tokenizer": [
          "int"
        ],
        "upsert": true
      }
    ]
  }
}

Indeed _predicate_ seems to be attached to default(ie. string) and not [string]!

{
        "predicate": "_predicate_",
        "type": "default"
      },
9

For the moment we didn’t play with list type nor @Lang.
Maybe I forget to say that we used :

  • Schema → Bulk Edit → DROP ALL feature from Ratel UI to start our scenario
  • Schema → Bulk Edit to store our tested schema

Does the bug could come from one of this feature?

I will try my scenario again starting from scratch.

10

Thanks @martinmr Updating _predicate_: [string] . solve our issue.

Predicate is now a string list.

   {
        "predicate": "_predicate_",
        "type": "string",
        "list": true
      },

Our schema is now :

{
  "extensions": {
    "server_latency": {
      "parsing_ns": 192,
      "processing_ns": 654
    },
    "txn": {
      "start_ts": 689470
    }
  },
  "data": {
    "schema": [
      {
        "predicate": "_predicate_",
        "type": "string",
        "list": true
      },
      {
        "predicate": "name",
        "type": "string",
        "index": true,
        "tokenizer": [
          "hash",
          "trigram"
        ]
      },
      {
        "predicate": "referent",
        "type": "string"
      },
      {
        "predicate": "referents",
        "type": "uid"
      },
      {
        "predicate": "type",
        "type": "string",
        "index": true,
        "tokenizer": [
          "hash"
        ]
      },
      {
        "predicate": "xid",
        "type": "int",
        "index": true,
        "tokenizer": [
          "int"
        ],
        "upsert": true
      }
    ]
  }
}
11

Thanks for confirming your schema. It does indeed look like _predicate_ changes type at some point although I haven’t been able to find out why or reproduce the issue although I have a feeling it might have to do something to do with the DropAll operation.

Also, thanks for confirming that the schema update works as a workaround.

12

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