Open james-whiteside opened 1 year ago
This would actually be quite cool if we ran full type inference on 'insert' queries as well - would be a great watch to solve this problem in generality!
Note: this may not be doable efficiently
We want to perform the following type check:
match
that are invalid in the insert
or delete
.This can be formulated that this query returns no answers:
match
$x-type...
$y-type...
$z-type...
not {
... insert typing requirements
}
This can be very expensive since all permutations of types for x/y/z will be checked against the not
. It is slightly more efficient if the traversal engine can know when to perform the negation checks, rather than doing it after every completed match
permutation.
Relatedly, this is the same issue as faced by efficient rule validation: https://github.com/vaticle/typedb/issues/6387
Description
If I run a match-insert query against a database and the match fails, the server gives a normal response, even if the insert pattern is not valid. Example is given below.
Environment
Reproducible Steps
Steps to create the smallest reproducible scenario:
Expected Output
Error is thrown as
person
does not ownphone
.Actual Output
TypeDB gives normal response (no inserts performed).