Officially out now: The TypeDB 3.0 Roadmap >>

Concept variables

Syntax

A concept variable is used in TypeQL as dollar sign ($) followed by the variable’s label:

$<variable-label>

Behavior

Concept variables in TypeQL represent unknown types and data instances in data query patterns.

When solving a pattern, each solution consists of variable/concept pairs for every query variable. Substituting variables with respective concepts from a solution should ensure that the pattern equals True.

Some TypeQL statements can imply type restrictions on a concept variable via type inference, for example:

  • sub, sub!, type, and owns can be applied only to types;

  • isa, has, and is can be used only with data instances to the left from them;

  • Any value operations, including arithmetic operations, comparators, built-in functions can be applied only to attributes.

Usage in a query

Let’s use has keyword to retrieve all attributes that owned by anything.

Fetching attributes
match
$x has $a;
fetch
$a;

The resulted JSON should look like this:

{ "a": { "value": "Masako Holley", "type": { "label": "full-name", "root": "attribute", "value_type": "string" } } }
{ "a": { "value": "masako.holley@typedb.com", "type": { "label": "email", "root": "attribute", "value_type": "string" } } }
{ "a": { "value": 1, "type": { "label": "id", "root": "attribute", "value_type": "long" } } }

Usage with variablized types

We can replace any type in a pattern with a concept variable and then retrieve such a variable to get the type (or rather all possible types):

Fetching types example
match
$x isa person, has $a;
$a isa! $type;
fetch $type;

Here we are matching all entities ($x) of the person type and all attributes that they have ($a). But then we match and fetch only the exact type of every attribute.

The resulted JSON should look like this:

{ "type": { "label": "full-name", "root": "attribute", "value_type": "string" } }
{ "type": { "label": "email", "root": "attribute", "value_type": "string" } }