You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am encountering an issue with Dgraph where I am unable to fully delete a node or the entire graph. Although I can delete individual predicates from a node, complete node deletion using either the JSON mutation syntax or RDF N-Quad format does not seem to work as expected. Instead of being fully removed, nodes turn into orphan nodes with no data but still apparently occupy space on disk.
Attempts to Delete a Node
JSON Mutation Query
{
"delete": {
"uid": "0x37..."
}
}
RDF N-Quad Format
{
delete {
<0x37...> * * .
}
}
In both scenarios, I am consistently facing issues with Dgraph where efforts to completely delete nodes using JSON mutations do not work as intended. Despite receiving a "done" success message, the node remains unaffected.
In the above case, the nodes are not entirely removed; they simply become empty objects. When I query these nodes post attempted deletion, they appear as empty or orphaned nodes, indicating that although their predicates have been cleared, the nodes themselves linger.
Environment Details
Dgraph Version: v24.0.1
Deployment: Standalone
RAM: 8GB
Disk Setup: HDD, 50GB
Number of Alpha Nodes: 3
Number of Zero Nodes: 3
Operating System: Debian GNU/Linux 12 (bookworm)
CPU: 2 cores
Requirement
The requirement is that when a node is deleted, not only should all its predicates be deleted but it should also be entirely removed from the disk to not waste space and possibly affect performance. This behavior is crucial for managing dynamic graphs where nodes are frequently created and deleted.
Please let me know if there are additional configurations or methods that should be followed to completely delete nodes and free up all associated resources, or if this might be a potential bug that needs addressing this memory leak.
Any assistance or clarification on this issue would be greatly appreciated, as it impacts our ability to efficiently manage storage and maintain the graph's integrity.
Thank you!
Tell us a little more about your go-environment?
Go version 1.20.2
Have you tried reproducing the issue with the latest release?
None
What is the hardware spec (RAM, CPU, OS)?
Dgraph Version: v24.0.1
Deployment: Standalone
RAM: 8GB
Disk Setup: HDD, 50GB
Number of Alpha Nodes: 3
Number of Zero Nodes: 3
Operating System: Debian GNU/Linux 12 (bookworm)
CPU: 2 cores
What do you mean object shouldn't exists? In Dgraph UID is just a identifier. It's uint64, and all the UIDs are technically empty objects in which you are adding some data. UIDs don't get deleted, you can keep reusing them.
Is there a more efficient way to delete nodes in Dgraph than removing all predicates to empty the object? If I only have the UID of the root node, is it possible to delete the entire graph? What is the optimal approach to delete an entire graph in Dgraph given the root node's UID?
What do you mean object shouldn't exists? In Dgraph UID is just a identifier. It's uint64, and all the UIDs are technically empty objects in which you are adding some data. UIDs don't get deleted, you can keep reusing them.
{
delete {
<0x123...> * * .
}
}
using this Mutation query, I am unable to empty the object/node
You can use the type feature to specify predicates of a given node: https://dgraph.io/docs/dql/dql-schema/#node-types
The reason your delete mutation doesn't work is because dgraph doesn't know which predicates the node has.
I don't think this is a bug.
Description
I am encountering an issue with Dgraph where I am unable to fully delete a node or the entire graph. Although I can delete individual predicates from a node, complete node deletion using either the JSON mutation syntax or RDF N-Quad format does not seem to work as expected. Instead of being fully removed, nodes turn into orphan nodes with no data but still apparently occupy space on disk.
Attempts to Delete a Node
JSON Mutation Query
RDF N-Quad Format
In both scenarios, I am consistently facing issues with Dgraph where efforts to completely delete nodes using JSON mutations do not work as intended. Despite receiving a "done" success message, the node remains unaffected.
Deleting all predicates one by one from a node
In the above case, the nodes are not entirely removed; they simply become empty objects. When I query these nodes post attempted deletion, they appear as empty or orphaned nodes, indicating that although their predicates have been cleared, the nodes themselves linger.
Environment Details
Dgraph Version: v24.0.1
Deployment: Standalone
RAM: 8GB
Disk Setup: HDD, 50GB
Number of Alpha Nodes: 3
Number of Zero Nodes: 3
Operating System: Debian GNU/Linux 12 (bookworm)
CPU: 2 cores
Requirement
The requirement is that when a node is deleted, not only should all its predicates be deleted but it should also be entirely removed from the disk to not waste space and possibly affect performance. This behavior is crucial for managing dynamic graphs where nodes are frequently created and deleted.
Please let me know if there are additional configurations or methods that should be followed to completely delete nodes and free up all associated resources, or if this might be a potential bug that needs addressing this memory leak.
Any assistance or clarification on this issue would be greatly appreciated, as it impacts our ability to efficiently manage storage and maintain the graph's integrity.
Thank you!
Tell us a little more about your go-environment?
Go version 1.20.2
Have you tried reproducing the issue with the latest release?
None
What is the hardware spec (RAM, CPU, OS)?
Dgraph Version: v24.0.1
Deployment: Standalone
RAM: 8GB
Disk Setup: HDD, 50GB
Number of Alpha Nodes: 3
Number of Zero Nodes: 3
Operating System: Debian GNU/Linux 12 (bookworm)
CPU: 2 cores
What steps will reproduce the bug?
Create a node, Let's say:
On success, it will create an uid. let's say <0x123...>
Get the Details:
Delete the Node:
Deleting all predicates one by one from a node
Expected behavior and actual result.
Expected Behavior:
The object with uid <0x123...> should no longer exist.
Actual Behavior:
Additional information
No response
The text was updated successfully, but these errors were encountered: