TypeDB 3.0: cascading deletes

[flyingsilverfin]

Problem to Solve

Currently, users have to manage deletion of dependent/connected relations manually when deleting entities or relations.

Current Workaround

Users have to manually query for connected desired relations and delete them in a separate query, before deleting the concept itself.

match
  $x has <key>;
  $m ($x) isa employment;
delete
  $m isa employment;

match
  $x has <key>;
delete
  $x isa thing;

Proposed Solution

Query-level cascades:

Allow specifying which types to cascade deletes into (polymorphically specifying is OK too!):

match
  $x has <key>;
delete
  $x isa thing @cascade(employment);

Note that cascade should cascade through relations recursively! In this example, if there are employment relations contained in employment relations, these should be recursively deleted as well.

We could also consider an extension which only cascades if a constraint is violated:

match
  $x has <key>;
delete
  $x isa thing @cascade(<employment if @card violated>);

Schema-level cascade

We consider using the SQL/postgres inspired specification at the schema level, which would be translated into specifying delete behaviour at the relation definition:

employment sub relation @cascade, relates employee;
employment sub relation, relates employee
employment sub relation, relates employee 

This annotation means the relation will be automatically deleted on cardinality violation.
This is contrasting to the default behaviour, where transaction commit would be rejected.

We should also help the user by introducing a query to check consistency of the data before commit, which will especially help with schema migrations and manual intervensions.

Within one transaction, we will allow cardinality to be violated, to allow mutating data in-place easily.

Extensions with greater flexibility

The cascade clause following a delete is a bit like the fetch clause: it makes the 95% common case extremely easy to express and use.

However, there are cases which may require greater flexibility: we may not want to recursively delete all connected relations of the specified types, but maybe only within a limited range, or with other general conditions (connected to neighbors with a specific attribute, whatever):

We can achieve such a generalised form by combining a match clause using trystatements, with a delete clause:

match
  $x isa person, has name "John";
  try { $m ($x) isa marriage; };
  try { $r ($x) isa other_type; <further constraints on $r>; };
delete 
  $x isa person;
  $m isa marriage;
  $r isa other_type;

Further, we could combine this with recursive query functions to traverse a specific depth of connected relations and delete these selectively.