Update query
An Update query is used to replace data in a TypeDB database.
This query deletes and then inserts data based on a given match
, delete
, and insert
patterns.
For a practical guide on how to send an Update query to TypeDB,
see the Update query page of the TypeDB Manual.
Syntax
match <pattern>
delete <delete_pattern>
insert <insert_pattern>
where both <delete_pattern>
and <insert_pattern>
are patterns of valid data-specific TypeQL statements including
isa / isa!,
has,
role assignment, and
value assignment.
The mandatory match
clause <pattern>
can be any valid match pattern: for more information, see the
Patterns and Statements sections.
Behavior
An Update query first deletes and then inserts data instances, ownerships, or role player assignments to a database.
The results of the match
clause in an Update query will be used for the variables in its subsequent
delete
and insert
clauses.
For more information and examples of the latter clauses,
see the Delete query and Insert query page.
Note that inserted data need not be a direct replacement for the data deleted by the same query. You can insert a new concept instead of a deleted one with either the same variable or a new one.
Query execution
The insert
clause is executed after the delete
clause of the same query and uses the same matched result
from the match
clause. For an Update query to succeed the following must be satisfied:
-
Data that is assumed to exist
insert
must not be deleted in the precedingdelete
clause. For example, deleting an entity and then trying to insert ownership of an attribute to that deleted entity (and without inserting a new entity its place). -
Inserted data must not violate a schema of a database.
Update ownerships
For this example, use a database with the IAM schema and sample data loaded.
In many cases, the desired effect is to change the value of an owned attribute. Attributes are immutable, and we can’t change a value of an attribute. But we can replace ownership: delete ownership of the old attribute and add a new one.
match
$p isa person,
has full-name "Masako Holley",
has email $email;
delete
$p has $email;
insert
$p has email "m.holley@typedb.com";
The above query does the following:
-
Matches all
person
entities ($p
) that have thefull-name
attribute with the value ofMasako Holley
amd have some$email
of typeemail
. -
Deletes from
$p
ownership of its matchedemail
attribute. -
Makes
$p
the owner of theemail
attribute with the value ofm.holley@typedb.com
.
If there are more than one $email
found for Masako Holley
person,
than there will be more than one result for the match
clause.
Both delete
and insert
clauses will be executed once for every matched result (for every $email
).
Inserting multiple ownerships of the same attribute for the same owner produces the same result as inserting one.
The old |
If you want to narrow down the matched results to a single unique entity, consider specifying uniqueness annotation for some of its attribute ownerships.
Update attributes
For this example, use a database with the IAM schema and sample data loaded.
Deleting an attribute deletes ownership of it from all its owners.
We can insert a new attribute instead of a deleted one without a problem,
because we match all data with a match
clause pattern before we start deleting and inserting.
match
$p isa person, has full-name $n;
$n contains "inappropriate word";
delete
$n isa full-name;
insert
$p has full-name "deleted";
The above query:
-
Finds all
person
entities ($p
) with at least one ownedfull-name
attribute ($n
). -
Filters
$n
(and consequently$p
) to only those that contain the substringinappropriate word
. -
Removes these
full-name
attributes that contain the substring from a database. -
Makes
$p
the owner of thefull-name
attribute with the value ofdeleted
.
Assuming there are some matches,
after running the above query, there will be a single full-name
attribute with a value of deleted
,
which is owned by the matched entities.
Any full-name
attributes which contained the substring inappropriate word
will no longer exist in the database.
Update role players
For this example, use a database with the IAM schema and sample data loaded.
To replace a role player, we combine the steps for deleting a role player with extending the relation:
match
$p isa person, has full-name "Pearle Goodman";
$a_write isa action, has name "modify_file";
$a_read isa action, has name "view_file";
$ac_write (object: $o, action: $a_write) isa access;
$ac_read (object: $o, action: $a_read) isa access;
$pe (subject: $p, access: $ac_write) isa permission;
delete
$pe (access: $ac_write);
insert
$pe (access: $ac_read);
The above query does the following:
-
Finds the
person
entity ($p
) with thefull-name
ofPearle Goodman
. -
Finds the
action
entity ($a_write
) with thename
ofmodify_file
). -
Finds the
action
entity ($a_read
) with thename
ofread_file
). -
Finds all
access
relations ($ac_write
) that relate anyobject
(asobject
) to$a_write
(asaction
). -
Finds all
access
relations ($ac_read
) that relate anyobject
(asobject
) to$a_read
(asaction
). -
Finds all permissions (
$pe
) that relate$p
(assubject
) to$ac_write
(asaccess
). -
Removes all write accesses (
$ac_write
) as a player of theaccess
role in matching permission relations ($pe
). -
Adds all read accesses (
$ac_read
) as a player of theaccess
role in matching permission relations ($pe
).
In short, all of Pearle Goodman’s permissions with the modify_file
access
become permissions with the view_file
access.
After running the above query, all matched access
relations $ac_write
with $a_write
as action
still
exist but no longer play a role in the matched permission
relations.