How to delete an empty node?

Users Dgraph
1

The following code seems to delete all BlogPost.comments:

const txn = dgraphClient.newTxn();

export async function post(request) {
  const deleteBlogPostComments = {
    query: `{ c as var(func: type(Comment)) }`,
    delete: [
      {
        "uid": "uid(c)"
      }
    ]
  }

  await txn.mutate({ mutation: JSON.stringify(deleteBlogPostComments) });
  await txn.commit();
}

If I run queryComment I get an empty array, if I query aggregateComment(){ count } I get 0.

However, if I query:

query{
  getBlogPost(slug: "a-slug"){
    comments {
      id
    }
  }
}

…I still get a array of comment ids.

And if I query for:

query{
  getBlogPost(slug: "a-slug"){
    comments {
      id
      textContent
    }
  }
}

…I get:

"errors": [
    {
      "message": "Non-nullable field 'textContent' (type String!) was not present in result from Dgraph.  GraphQL error propagation triggered.",

Why does this happen?

Presumably I need to delete the edges from BlogPost to orphan nodes / orphan ids / whatever they are, and then this isn’t a problem anymore? I’m guessing the remaining IDs are merely edges that now link to nothing?

EDIT:

Presumably I need to delete the edges from BlogPost to orphan nodes / orphan ids / whatever they are, and then this isn’t a problem anymore?

To confirm, deleting these edges fixes the non-nullable field error, however, I still have the following questions:

  • Am I right in saying that the array of IDs are merely edges to nowhere?
  • How would I do the above (delete all BlogPost.comments with relevant edges) using RDF syntax in Ratel??
1 Like
2

Here is a reference:

In theory, almost. Every uid list are “merely edges to nowhere” if that is how you want to look at it. A list of uids is a “list of uids” whether those uids have any triples stored in the graph or not.

Yourself coming from the GraphQL API down to the DQL lang itself you are seeing some of the power of the API that you don’t get. You have to now control the deletes of the * * O variety when Dgraph does not allow deletes of this variety.

In the API the schema shows everywhere possible for these uids to exist when being deleted and runs a S P O delete for each possible location where S is each possible pare node P is each edge and O is the node being deleted.

This again shows the need why we need something like the following not only in the GraphQL API, but also in the DQL language itself:

1 Like
3

October 2022 over here, getting the same error, I delete a record with a mutation and get the same error when refetch the list. Deleting the record will delete all the object keys but not the record id, so a ghost empty record is left in the data base…

Screen Shot 2022-10-01 at 3.16.32 AM
Screen Shot 2022-10-01 at 3.16.32 AM800Ă—232 3.71 KB

Mutation:

mutation deleteRepairCode($id: [ID!]) {
  deleteRepairCode(filter: {id: $id}) {
    msg
  }
}

// query variables:
{
  "id": "0xfffd8d6ab2e2dcf4"
}

Solution so far is to use @cascade in the query to filter out the empty records, but Im not sure of the long term impact all this ghost empty records might have

1 Like
4

They are called “null node”. And the impact, from my calculations, it would be something in 100 years in order to see an issue with this. I think that in less then a decade you might start your DB setup from scratch a few times. And those null nodes won’t be exported. Cuz Dgraph doesn’t export nodes with no values.

BTW. One thing to take into account is that on every reimport of the exported data. You use a flag explicitly asking for new uids. Because if you keep the default, it will increase the range of UIDs(long history to explain why). And these null nodes will reappear as a consequence.

PS. We can’t do anything about null nodes. They will exist because of a design maxim. Now, dangling edges is another story(and I think that was the case of this whole conversation. Not null nodes or “ghost nodes”) which is a manual problem that you can solve by creating a simple logic in your end. Which we can’t introduce into the DB design, because that would make Dgraph too slow. But Null Nodes will exist by design, you just need to ignore them.

3 Likes
5

Noicee !! I think I can take 100 years ! :rofl:
Good to know thanks for the light, Im gonna just move forward and just use @cascade, it doesn’t seems like a bid deal :pray: :muscle: thank you @MichelDiz

1 Like
6

:grimacing: hope you don’t need to paginate.

1 Like
8

@Rolando if you want to get rid of dangling edges, you can query for those if the original node had a mandatory field. Eg:

type Node {
  id: ID!
  edge: Edge
}

type Edge {
  id: ID!
  field: String!
}

Then you can query

{
  "query": "{ q(func: type(Node)) { n as uid Node.edge @filter(NOT has(field)) { e as uid } } }",
  "mutations": [
    {
      "delete": {
         "uid": "uid(n)",
         "Node.field": { "uid": "uid(e)" }
       }
    }
  ]
}

Probably this also works if there is no mandatory field defined.

1 Like
9

I also used a filter just like @Poolshark is saying, I mean not exactly that code but similiar.
But also I need to paginate actually so I will have to figure something once I get there…

@amaster507 Does @cascade don’t allow you paginate or something? have to check the docs

1 Like