So, yes, dgraph can fix this problem by implementing my feature suggestion (I also talk about the basic hack for now in this link):
However, there is a bigger issue here. I think we don’t always think about things the way they are. Dgraph handles arrays as shared arrays unlike a noSQL database in example.
Example
Type Item {
id: ID!
name: String! @id
...
}
Type Cart {
items: [Item]
...
}
If we have something like:
items: [bread, butter, eggs...]
those items may be shared by other nodes.
While we can use the mutation-->update-->remove method to remove the link, we are also leaving the node by itself, a phantom node, unless another node is linked to it. This is a problem.
Say I have the item juicy fruit blue flavor in my cart. Once I remove that item from my cart, it is never sold again. There will never be another node that needs to link to it. Now, I have a phantom node.
I can’t tell my @cascade delete to delete all items if I delete my cart. Other people have the items in their cart.
Dgraph obviously lacks this feature for that case (but they didn’t consider the more prominent cases where you do want to cascade delete).
Should there be phantom nodes (orphans)?
Yes and No. It depends, or it doesn’t. Do I really need a node with all possible zip codes or states, even if I do not have addresses in my DB using all of them. Well, how do you search for them then?
So, yes, you may want to have all zip codes readily available for your client. The reason this is not really a phantom node is because you have a need to search for them separately from the address. If you don’t need that feature, then you do want @cascade delete to work every time. I don’t think it would be considered a phantom node because of that. So, no, you don’t want phantom nodes, but we need to look at what a phantom node really is.
Gum solution
In the above problem, a perfect solution would be to delete the juice fruit blue node, only when the links are 0. You really need a stored procedure to do this in mysql, as @reference directive won’t do this alone.
Side note feature request: Delete item automatically if no connections. This basically says node cannot exist on its own. Maybe a @dependence(field: cart) directive or something.
Other option
So basically we just have to be careful on our DATA MODELING before we do anything else. The above example would probably be better like so:
Type Items {
id: ID!
name: String!
...
}
Notice I did NOT use @id on name here. You may have repeated data (i.e. lots of people with bread in their cart), but your data is much cleaner, and it is easier to hack the @cascade delete to keep your data clean. See my other posts for how to @cascade delete in the current state of dgraph.
Just some random thoughts I had to get out of my head.
J