Light
Dark
System
v2latest
v3dev
v2latest
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 {
  property name -> str;
  property all_caps_name := str_upper(__subject__.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 __subject__ to refer to the current object; it’s analogous to this or self 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.

Copy
type Person {
  property first_name -> str;
  property 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 {
  property 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 link members -> Person;
  multi link active_members := (
    select .members filter .is_active = true
  )
}

type Person {
  property name -> str;
  property is_active -> bool;
}

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

Copy
type BlogPost {
  property title -> str;
  link author -> User;
  required property 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