Properties

Properties are used to associate primitive data with an object type or link.

  1. type Player {
  2. property email -> str;
  3. property points -> int64;
  4. property is_online -> bool;
  5. }

Properties are associated with a key (e.g. first_name) and a primitive type (e.g. str` ). The term primitive type is an umbrella term that encompasses scalar types like str and bool, enums, arrays, and tuples.

Required properties

Properties can be either optional (the default) or required.

  1. type User {
  2. required property email -> str;
  3. }

Property cardinality

Properties have a cardinality, either single (the default) or multi. A multi property of type str points to an unordered set of strings.

  1. type User {
  2. # single isn't necessary here
  3. # properties are single by default
  4. single property name -> str;
  5. # an unordered set of strings
  6. multi property nicknames -> str;
  7. # an unordered set of string arrays
  8. multi property set_of_arrays -> array<str>;
  9. }

Comparison to arrays

The values associated with a multi property are stored in no particular order. If order is important, use an array. Otherwise, multi properties are recommended. For a more involved discussion, see EdgeQL > Sets.

Default values

Properties can have a default value. This default can be a static value or an arbitrary EdgeQL expression, which will be evaluated upon insertion.

  1. type Player {
  2. required property points -> int64 {
  3. default := 0;
  4. }
  5. required property latitude -> float64 {
  6. default := (360 * random() - 180);
  7. }
  8. }

Readonly properties

Properties can be marked as readonly. In the example below, the User.external_id property can be set at the time of creation but not modified thereafter.

  1. type User {
  2. required property external_id -> uuid {
  3. readonly := true;
  4. }
  5. }

Constraints

Properties can be augmented wth constraints. The example below showcases a subset of EdgeDB’s built-in constraints.

  1. type BlogPost {
  2. property title -> str {
  3. constraint exclusive; # all post titles must be unique
  4. constraint min_len_value(8);
  5. constraint max_len_value(30);
  6. constraint regexp(r'^[A-Za-z0-9 ]+$');
  7. }
  8. property status -> str {
  9. constraint one_of('Draft', 'InReview', 'Published');
  10. }
  11. property upvotes -> int64 {
  12. constraint min_value(0);
  13. constraint max_value(9999);
  14. }
  15. }

You can constrain properties with arbitrary EdgeQL expressions returning bool. To reference to value of the property, use the special scoped keyword __subject__.

  1. type BlogPost {
  2. property title -> str {
  3. constraint expression on (
  4. __subject__ = str_trim(__subject__)
  5. );
  6. }
  7. }

The constraint above guarantees that BlogPost.title doesn’t contain any leading or trailing whitespace by checking that the raw string is equal to the trimmed version. It uses the built-in str_trim() function.

For a full reference of built-in constraints, see the Constraints reference.

Annotations

Properties can contain annotations, small human-readable notes. The built-in annotations are title, description, and deprecated. You can declare custom annotation types.

  1. type User {
  2. property email -> str {
  3. annotation title := 'Email address';
  4. annotation description := "The user's email address.";
  5. annotation deprecated := 'Use NewUser instead.';
  6. }
  7. }

Abstract properties

Properties can be concrete (the default) or abstract. Abstract properties are declared independent of a source or target, can contain annotations, and can be marked as readonly.

  1. abstract property email_prop {
  2. annotation title := 'An email address';
  3. readonly := true;
  4. }
  5. type Student {
  6. # inherits annotations and "readonly := true"
  7. property email extending email_prop -> str;
  8. }

Properties can also be defined on links. For a full guide, refer to Guides > Using link properties.

See also

SDL > Properties

DDL > Properties

Introspection > Object types.