Light
Dark
System
v3latest
v3latest
v2
v1

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.

Copy
type Person {
  name: str;
  property all_caps_name := str_upper(__source__.name);
}

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.

Volatile functions are not allowed in computed properties defined in schema. This means that, for example, your schema-defined computed property cannot call datetime_current(), but it can call datetime_of_transaction() or datetime_of_statement(). This does not apply to computed properties outside of schema.

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

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

Copy
type Person {
  first_name: str;
  last_name: str;
  property full_name := .first_name ++ ' ' ++ .last_name;
}

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.

Copy
type Person {
  first_name: str;

  # this is invalid, because first_name is not a required property
  required property first_name_upper := str_upper(.first_name);
}

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

Copy
type Club {
  multi members: Person;
  multi link active_members := (
    select .members filter .is_active = true
  )
}

type Person {
  name: str;
  is_active: bool;
}

Using a computed property, you can timestamp when an object was created in your database.

Copy
type BlogPost {
  title: str;
  author: User;
  required created_at: datetime {
    readonly := true;
    default := datetime_of_statement();
  }
}

When a BlogPost is created, datetime_of_statement() will be called to supply it with a timestamp as the created_at property. You might also consider datetime_of_transaction() if that’s better suited to your use case.

Light
Dark
System

We use ChatGPT with additional context from our documentation to answer your questions. Not all answers will be accurate. Please join our Discord if you need more help.