Deleting data
This page explains how to delete data from a TypeDB database.
Understanding delete pipeline stages
A delete stage is used to delete data from a TypeDB database.
It can be used in a pipeline to operate variables declared on a preceding match stage.
Refer to the Delete stage page for detailed explanation and more examples.
Sending delete pipelines
|
The examples below can be combined with the following schema file. A part of this file is defined in the respective definition manuals. Also, the data deleted in these examples is inserted in the insertion manual. See the schema.tqlschema.tql
|
Delete an instance
To delete data, open a write transaction.
This allows you to read and write data to your database while keeping the schema secure.
Every deletion begins with an delete, but also requires some input, so a preceding match stage is needed to produce concepts incoming to the delete stage.
The logic is similar to inserting data based on a match: the variables, declared in the match stage, can be used in the delete stage to control the deletion process.
Similarly, multiple statements can be combined to delete multiple instances or connections.
To delete a type instance (an entity, a relation, or an attribute), declare a $var for this instance and add delete $var:
match
$u isa user, has username "User";
delete
$u;The following pipeline will act in two stages:
-
The first stage will match all
users withusername"User" (asusernameis a key in the schema, you can be ensured that only oneuserwill be found). -
The second stage will delete the matched
users (the onlyuserwithusername"User").
|
Take into account that default relations and attributes without certain annotations can be cleaned up on commit if they are not relating or owned by any other instance, so deleting a single entity can lead for more cascading cleanups. For example, the |
Similarly to insert stages, delete s have the same sets of data constraints to check after every operation or before a commit.
Delete an instance’s ownership
To delete only a specific trait instance, mention what you want to delete and what instance it relates to.
In case of an ownership instance, write an expression like has $attribute of $owner using the has statement and the keyword of pointing to the owner:
match
$a isa user, has username "Alice", has email $email;
delete
has $email of $a;|
This query only deletes the |
The verbose way to delete both the ownership and the attribute is:
match
$a isa user, has username "Alice", has email $email;
delete
has $email of $a;
$email;However, it is redundant as the deletion of an instance also deletes all its connections. Thus, it can be written as:
match
$a isa user, has username "Alice", has email $email;
delete
$email;Delete a relation connection
Similarly, a connection between a relation and its roleplayers can be deleted. A single role or multiple roles can be deleted using the following query:
match
$b isa user, has username "Bob", has email "bob@typedb.com";
$c isa user, has username "Charlie", has email "charlie@typedb.com";
$f isa friendship, links (friend: $b, friend: $c);
delete
links ($b, $c) of $f;
links ($b) of $f;|
The |
Response interpretation
A delete stage takes the input from the previous pipeline stages, processes the deletions and returns the concepts left from the input. All the deleted concepts are not shown in the output. This way, another pipeline stage can take this as an input and continue data processing.
For example, the example of a user instance deletion where there are no concepts left for the output produces the following TypeDB Console’s response:
No columns to showAt the same time, a has deletion does not affect the output, as both concepts are still in the database until a commit:
has deletion ------------
$email | alice@typedb.com isa email
$u | iid 0x1e00030000000000000002 isa user
------------However, if you delete the email itself:
------------
$u | iid 0x1e00030000000000000002 isa user
------------Preserving or reverting changes
Do not forget to commit your transaction to preserve the changes. As mentioned earlier, some data constraints are only validated upon commit. This means you might discover inconsistencies in your data during the commit process, and the commit will be rejected.
While most validations occur during operation time to keep data synchronized, commit-time validations are necessary to allow flexible data modifications. For example, validating inserted data against cardinality during operation time could block modifications entirely.
If you want to abort your changes, simply close the transaction or perform a rollback. Refer to Transactions for more details.
Having troubles?
Refer to the Debugging queries page for common debugging tips.