Hard time trying do delete things

Hi. I like the way DGraph querys “just work”. You set a JSON, and bam! What you J(son) is what you G(et).

The same can not be said about delete operations. There are really common scenarios of day to day work that I just cant got to work.

Say that you have a “tags” kind of node ({__is_tags: true, tag: “MyTag”}) and you’ve been tagging so many things with it for like two or three months. Many “__is_something” nodes in your DB has the tag MyTag associated. Then I change my mind and do not like MyTag anymore. I want to delete it.

How do I do that? I was hoping that a
{ delete { <0x27> * * . } }

would do, but all I got is a “Transaction aborted error”.

Im just supposing thats because it has so many relationships with so many nodes, but do I really have to write a code to scan all my possible “__is_stuff” to check if is there a relation, and then delete that relation first?

How do I know or do I get ALL nodes related do MyTag? Remember that the relation is set from “Stuff” to “Tag”. What do I do now?



1 Like

I was about to start a similar thread; deleting stuff feels really hard.

Right now I’m getting error with the message:

rpc error: code = Unknown desc = Please use * with delete operation for non-list type: [myNodeName]

Despite having replaced string values with *, and in case my data type is time.Time or bool or something else then I’ve tried to create a new struct with same dgraph json node names but using only strings with the * value.

Tried to delete using both:

mut := &api.Mutation{CommitNow: true}
mut.DeleteJson = myJson
dgo.Dgraph.NewTxn().Mutate(context.Background(), mut)


mut := &api.Mutation{CommitNow: true}
dgo.DeleteEdges(mut, uid, "uid", "someStringNode", "someBoolNode", "someSliceNode", "someTimeNode")
dgo.Dgraph.NewTxn().Mutate(context.Background(), mut)

but it’s been unsuccessful, and I can’t find any alternative methods. I’m curious why it isn’t possible to delete everything associated with an uid by simply providing the uid (assuming it is impossible).

Hey @tlmichael, try to delete it this way to delete an edge:

mu = &api.Mutation{}
dgo.DeleteEdges(mu, alice, "friends", "loc")

mu.CommitNow = true
_, err = dg.NewTxn().Mutate(ctx, mu)
if err != nil {

resp, err = dg.NewTxn().QueryWithVars(ctx, q, variables)
if err != nil {

To delete a node:

d := map[string]string{"uid": alice}
pb, err = json.Marshal(d)
if err != nil {

mu = &api.Mutation{
    CommitNow:  true,
    DeleteJson: pb,

_, err = dg.NewTxn().Mutate(ctx, mu)
if err != nil {
1 Like

For complete example, you can check :

If there’re mutations flowing through the system at the same time, it’s possible that transactions are conflicting and causing aborts. Retrying it should fix the issue.

We also plan to tighten up the conflict detection, so it doesn’t flag so many conflicts, which cause aborts – in a near-future release.

Thanks, I indirectly tried something similar (by having omitempty, e.g. json:"myNodeName,omitempty" on my struct while only supplying uid).

I just now realize that this does perhaps mean that it was successfully deleted, except in my case then the uid is signed to another uid via a predicate (if that makes any sense)…

In other words, I have these two structs:

type CommentNode struct {
	ThreadUid string    `json:"uid,omitempty"`
	Comments  []Comment `json:"comments,omitempty"`
type Comment struct {
	Uid          string    `json:"uid,omitempty"`
	NodeType     string    `json:"nodeType,omitempty"`
	Content      string    `json:"content,omitempty"`
	CreationTime time.Time `json:"creationTime,omitempty"`
	User         []User    `json:"user,omitempty"`

When I create a new Comment then I sign it to the CommentNode.ThreadUid via the CommentNode.Comments predicate, and save it via CommentNode marshaled (not sure if I just butchered the Dgraph terminology, rephrasing what MichelDiz wrote :stuck_out_tongue: ).

So if I try to query the comment uid after deleting it, then the query will only return the uid itself (which I believe would indicate it was successfully deleted)… but even after deleting it, if I query the thread uid then it will still return the deleted comment uid.

Well I am too having the same issue here -

I figured it out, our/my problem is that we only deleted the uid, but we didn’t delete the signed uid predicate.

In my case I just had to delete the comment uid, as well as delete the thread uid+comment uid association, e.g.

pb := []byte(fmt.Sprintf(`[{"uid":"%s","comments":{"uid":"%s"}},{"uid":"%s"}]`, thread.ThreadUid, comments.Uid, comments.Uid))

Well this is what I was doing previously.
But if you read the full post from the following link then @MichelDiz had said that it is not necessary to delete the edge to which the node is connected. Only the UID of the comment node is enough. The UID should be deleted but some how it is still returning.

BTW, there is a temporary solution to this by using filters suggested by @MichelDiz here

1 Like

Ahh great, I like the @filter(has(comment.body) solution, will definitely be using that (:

1 Like

Just for the information sake, which version of Dgraph are you using?

I already use that approach by implementing a “remove()” function that actually flags an “__is_deleted” value on the nodes, and then my “query()” function do the correct filter. But sometimes you really want do DELETE things.

If there’re mutations flowing through the system at the same time, it’s possible that transactions are conflicting and causing aborts. Retrying it should fix the issue.

Thats mean that I should do a retry on a try catch? I’m pretty sure that no other mutation is running along side my test though.

I’m on 1.0.5


Well, all I’ve got is the same “Transaction has been aborted. Please retry” over again.

Is this a bug?

If I really have to delete the inbound relations, I would call it a bug. And I think this would bring us to the “how to find all inbound edges of a node” again.


Hey @tlmichael, You were right here,

We must delete the edge from parent to child node and the child node itself.
The answer has been updated here -

Thanks for the update :slight_smile:

And sorry to labs20 for hijacking your thread, it wasn’t my intention… just figured we were dealing with similar issues.

Yes, we are really sorry @labs20. :no_mouth::sweat_smile:

Nah, no worries. You may start to notice some shady men following you back home at night but youll be fine … =]

Well Glad to see that question solved but I still need help here.

1 Like

Ok, did a new test round and found that if I create new tags and relationships, I can delete them with no problem, but the old ones are hard to die.

I’m starting to assume that this can be something wrong with my database, as I didnt follow the whole export / bulk load thing back when moving from 1.0.4 to 1.0.5. Could it be?

I can provide an export of it for you guys if you want look it closer.