To get q ConceptMap simply iterate on lazy stream or iterator returned in a response to a Get query.

To retrieve a database concept from a ConceptMap, use Driver API ConceptMap.get(variable) method, that takes input of variable label and returns a Concept. Further processing of a Concept is done via Driver API methods

A Get query can return fewer results, than answers matched by its match clause. That is due to natural deduplication of results. See an example below.

In the above example match clause matches all person type instances that own a name attribute. The get clause then returns those attributes.

What happens if two persons have the same name? In TypeDB database that is stored, as two entities own the same attribute (instance of the name attribute type). The match clause finds all pairs of a person entity and its owned attribute. But get clause returns only the attributes. Since both persons own the very same attribute, it will be returned only once, reducing the total number of results.

For more examples of filtering matched results, see the Permutations and Variables filtering.

Use the sort keyword followed by a variable to sort the results. A second argument is optional and determines the sorting order: asc (ascending, by default) or desc (descending).

This query returns sorted full-name attributes owned by person entities.

To sort by multiple variables, add additional variables with a comma separator.

Use the offset keyword followed by the number to offset the results. This is commonly used with the limit keyword to return a desired range of results for pagination. Don’t forget to sort the results to ensure more deterministic and predictable results.

The above example sorts the full-name attributes of all person entities in ascending order, skips the first six results, and returns up to the next ten.

Use the limit keyword followed by a positive integer to limit the number of results (answers) returned.

The above example returns only one single (and random) instance of type person.

We recommend using the limit with the sorting aggregation to get more deterministic and predictable results.

We use the group function, optionally followed by another aggregate function, to group the results by the specified matched variable.

The output format is a lazy stream/iterator of ConceptMapGroup objects, that have owner and ConceptMaps methods/fields.

The above example returns the full-name attributes of all person entities, the path attributes of the object entities in any access relations that are part of the permission relation with the person entities, and the name attribute of the action entity in those access relations. The results are then sorted by the path attribute in ascending order, limited by only the first three results, and grouped by path variable values.

The following or similar result can be obtained by running the query above without inference on the TypeDB server with the IAM schema and dataset from the Quickstart guide.

There can be a difference in the full-name attribute returned for the README.md path group because the file with path README.md is owned by multiple persons, and we are not sorting by the full-name. To avoid that, we need to sort not only by $o-fp, but also by the $x-n variable: sort $o-fp, $x-n;

Aggregation performs a calculation on a set of values and returns a single value.

TypeDB supports the following types of aggregation:

To perform aggregation in TypeDB, we add an aggregation function at the end of a Get query. Aggregation function uses data returned by a preceding get clause to perform aggregation and return an aggregated result.

A simple Get query example:

The above query uses only two variables: $p and $e. The full-name attribute is not bound to a variable in this query.

The example above matches person ($p) with ownership of the full-name attribute with a value of Kevin Morrison and the email attribute ($e) with any value. The get clause then filters the results to retrieve only the email ($e) attributes.

The response is a stream/iterator of ConceptMap. Every ConceptMap bounds the variable $e to an attribute of the email type, that matches the pattern.

Let’s try a bit more complex pattern with some modifiers:

The example above uses a match clause to find data that matches the following conditions:

The get clause then filters the matched answers from the match clause to get only the concepts for the $x-n, $act-n, $o-fp variables.

The results are sorted and grouped by the $o-fp and aggregated with the count function.

The response is the number of results for every $o-fp: number of pairs $x-n and $act-n.

If there are multiple variables returned in every result, then results of a query include all permutations of answers.

To illustrate that behavior, let’s see what happens if we have three person entities and ten file entities in a database with the IAM schema and send the following get query:

How many results are we expecting to retrieve from a database?

As the example above doesn’t have any modifiers, aggregation, or grouping, the number of results will depend on the number of matched solutions for the pattern in the match clause. So the TypeDB query processor will explore all possible solutions: each consisting of one person entity and one file entity. There are only 3 * 10 = 30 possible combinations of person and file entities, so we will get 30 results.

See the Patterns overview section of the Matching patterns page for more information.

For the following example, consider the following database schema:

Let’s explore the following query:

The above query will find every person entity that has ownership over the instance of the attribute type name with the value of Bob, ownership of the age with the value of 31, and the ownership of the certified-fortune-teller attribute with any value.

With the get clause, we filter the results to get the person instances and the corresponding certified-fortune-teller attribute (represented by the $cft variable in the pattern) for every matched result in a database.

Why not filter for just the $cft variable instead?

That can drastically alter the returned results as the returned results are deduplicated by design. See the Basic patterns page for more information on the number of results for pattern matching.

For example, let’s say we have ten people with the name Bob and age 31 in our database. Five of them have certified-fortune-teller with the value false, one has it as true, and the rest don’t have an ownership of the attribute.

Those Bobs that don’t have the attribute ownership won’t be matched by the match clause at all. So we expect to get six results from the original Get query: five person instances owning the attribute with value false and one with true.

If we remove the $p variable and use get $cft; clause instead, we’ll get only two results in response because we will only get certified-fortune-teller instances, and there are only two of those: an instance with the true value and another instance of the same type with the false value.

The initial five instances of person type all have ownership over the same instance of the certified-fortune-teller attribute type with the value false.

To get all the results, we add the person type instances to the results because those are unique. Even if some of them might have the exact same set of owned attributes, instances of the person type are different instances nonetheless.

To try the get queries in that example, we need to load the schema and the dataset provided above into a TypeDB database first.