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.
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.
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.
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.
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;
}Backlinks are one of the most common use cases for computed links. In EdgeDB links are directional; they have a source and a target. Often it’s convenient to traverse a link in the reverse direction.
type BlogPost {
property title -> str;
link author -> User;
}
type User {
property name -> str;
multi link blog_posts := .<author[is BlogPost]
}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.
Using a computed property, you can timestamp when an object was created in your database.
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.
