Change to soft delete

[NoisyFlowers]

We want to change all of the delete operations provided through the api to be soft deletes, keeping the node and its relationships around but inaccessible without explicit consideration of their deleted status.

[NoisyFlowers]

I think the best implementation of soft delete will be to change the node labels (what we informally call the node type). For instance, Reference would become something like _Reference. This way, the nodes will disappear without need to rewrite all our other cypher to accommodate a "deleted" property. Similarly, the relationships that node is a part of will also be relabeled.

Soft delete leaves us with the same question regarding relationships that I had to deal with when I wrote the hard deletes:

1. Do we automatically re-lable all relationships for that node?
2. Or do we deny the delete operation and throw it back to the user to deal with the other end of those relationships first?
3. Or do we do something in between, choosing what relationships we think are ok to automatically delete and what to throw back to the user?

I opted for 3 when I wrote the original hard delete routines. For instance, when deleting a Schema, I strip the AUTHORED_BY and CITED_BY relationships, but I leave the CHARACTER_OF relationships untouched. This causes the delete to fail until the user first deletes the Characters. And, in turn, the user must delete the States of those Characters before the Character can be deleted. This sequence makes intuitive sense.

But, what if the user wants to delete a Reference node? Currently, I strip the old AUTHORED_BY relationships, but don't touch the CITED_BYs. This causes the delete to fail until the user does something about those CITED_BYs. But what do I expect the user to do about them? We can't expect him to delete the Schema on the other end. So maybe I should just go ahead and delete the CITED_BYs. But what does it mean that Schema suddenly loses a Reference?   We'll have to evaluate the delete of each node type to decide what actions are proper.

[aazaff]

We should discuss this at the next meeting.

[aazaff]

My notes from our discussion

State ! has_state Character ! state_of | instance_of Schema ! application_of | character_of Reference ! Cited_By CharacterInstance Description ! Defined_By | Candidate_For Specimen ! Described_By Organ NOT DELETABLE Role NOT DELETABLE Person NOT DELETABLE

Cascading Schema -> Character -> State -> State Description -> CharacterInstance

Additional Notes CharacterInstance cannot have both Defined_By and Candidate_for

[NoisyFlowers]

Reference cannot delete if CITED_BY

Schema cannot delete if CHARACTER_OF (can cascade) cannot delete if APPLICATION_OF

Character cannot delete if STATE_OF (can cascade) cannot delete if INSTANCE_OF

State cannot delte if STATE_OF (can cascade) cannot delete if HAS_STATE

CharacterInstance can always delete

Description cannot delete if DEFINED_BY (can cascade) cannot delete if CANDIDATE_FOR (can cascade)

Specimen cannot delete if DESCRIBED_BY

Organ cannot delete ever

Role cannot delete ever

Person cannot delete ever

[NoisyFlowers]

This is complete with commits 90f40b858ae74ec4acf9bef3836e8e6dfcaf4b49 through a197fbf46a6bd38483995a61b12e03fe473e5f6d

[NoisyFlowers]

I should add that I made cascade delete optional via a parameter in the xInput types of cascadable nodes. On the client, this is set with a checkbox.