Computed properties and links​

This section assumes a basic understanding of EdgeQL. If you aren’t familiar with it, feel free to skip this page for now.

Object types can contain computed links and properties. Computed properties and links are not persisted in the database. Instead, they are evaluated on the fly whenever that field is queried.

  1. type Person {
  2. property name -> str;
  3. property all_caps_name := str_upper(__subject__.name);
  4. }

Computed fields are associated with an EdgeQL expression. This expression can be an arbitrary EdgeQL query. This expression is evaluated whenever the field is referenced in a query.

Computed fields don’t need to be pre-defined in your schema; you can drop them into individual queries as well. They behave in exactly the same way. For more information, see the EdgeQL > Select > Computeds.

Leading dot notation​

The example above used the special keyword __subject__ to refer to the current object; it’s analogous to this in many object-oriented languages.

However, explicitly using __subject__ is optional here; inside the scope of an object type declaration, you can omit it entirely and use the .<name> shorthand.

  1. type Person {
  2. property first_name -> str;
  3. property last_name -> str;
  4. property full_name := .first_name ++ ' ' ++ .last_name;
  5. }

Type and cardinality inference​

The type and cardinality of a computed field is inferred from the expression. There’s no need for the modifier keywords you use for non-computed fields (like multi and required). However, it’s common to specify them anyway; it makes the schema more readable and acts as a sanity check: if the provided EdgeQL expression disagrees with the modifiers, an error will be thrown the next time you try to create a migration.

  1. type Person {
  2. property first_name -> str;
  3. required property name_upper := str_upper(.name); # invalid
  4. }

Common use cases​

Filtering​

If you find yourself writing the same filter expression repeatedly in queries, consider defining a computed field that encapsulates the filter.

  1. type Club {
  2. multi link members -> Person;
  3. link active_members := (
  4. select .members filter .is_active = true
  5. )
  6. }
  7. type Person {
  8. property name -> str;
  9. property is_active -> bool;
  10. }

Backlinks are one of the most common use cases for computed links. In EdgeBD links are directional; they have a source and a target. Often it’s convenient to traverse a link in the reverse direction.

  1. type BlogPost {
  2. property title -> str;
  3. link author -> User;
  4. }
  5. type User {
  6. property name -> str;
  7. blog_posts := .<author[is BlogPost]
  8. }

The User.blog_posts expression above uses the backlink operator .< in conjunction with a type filter [is BlogPost] to fetch all the BlogPosts associated with a given User. For details on this syntax, see the EdgeQL docs for Backlinks.

SDL > Links

DDL > Links

SDL > Properties

DDL > Properties