CODEWITHSUNDEEP
neo4jsoft-deleteneo4jphpneo4j-node
Somnath Muluk
Somnath Muluk

Reputation: 57656

How to soft delete functionality in neo4j?

In relational databases like mysql I was used to do soft delete by setting deleted_at. And then for retrieving SELECT just get rows WHERE deleted_at IS NULL.

I am confused how to implement soft delete in neo4j database. There are multiple ways I am getting but not sure which method or combination will have more advantages.

I also read Neo4j: implementing soft delete with optional relationships but not helping.

  1. Just set property of node deleted_at.
  2. Remove node label and change by prefix "_" like "Student" will become "_Student"
  3. Remove relationship and change by prefix "_" like "TEACHES" will become "_TEACHES"

Which will be best way or combination or other way to achieve soft delete in neo4j?

Upvotes: 3

Views: 985

Answers (2)

Satish Shinde
Satish Shinde

Reputation: 2996

I think have a deleted_at property for node. In which you can store deleted time-stamp.

And at the time of fetching nodes information you can check deleted_at IS NULL. like -

  MATCH (n:node)
  WHERE n.deleted_at IS NULL
  RETURN n;

Storing time-stamp you can get when node is deleted.

You can also have relationship deleted_by between user who deleted the node. So that you can find out who deleted node.

Upvotes: 2

FrobberOfBits
FrobberOfBits

Reputation: 18002

Which way is the best way will be debatable. If you don't need the actual date of soft delete, then you can just apply/remove a label as necessary:

Mark as "soft deleted":

match (a {name: "foo"}) set a:deleted return a;

Unmark:

match (a {name: "foo"}) remove a:deleted return a;

If you need to assert properties about the soft delete, then it makes sense to model it as a node (e.g. a "soft deletion event") and then link it to the node via a relationship. The nodes that are deleted then are any nodes of a certain type that have a "DELETED" relationship that goes to a soft-delete node. That soft delete node would then have a deleted_at property, along with anything else about the deletion event you're modeling.

I don't think a simple deleted_at property in the node is as good of a solution, because it confuses the node information with the information about the deletion event. I would argue you're trying to model a deletion event here.

Upvotes: 4

Related Questions