This is a general purpose type, suitable for a wide range of entities and concepts. It supports unique values, and may be a singleton.
The Universal type may optionally be a container for other types.
For example, a
List might be defined as a container for
While this type has broad cases, review the other model types before choosing in case another type is more suitable. It does not allow large text fields, and is therefore not suitable for an article, blog post, or product description.
Represents content that is handcrafted by a small number of people, and typically viewed by a much wider audience. Intended for content management systems, and it may represent anything from an Article to a Product.
It supports a larger field size for the rich text field type, as well as a larger overall model size. Because it is intended to be created and managed by people, only 1 insert is allowed per transaction/request.
Profiles are a type of model which allows associating custom fields with a specific user. They are only available when user related functionality is enabled. They may either be top level or contained.
Embedded models create a complex value (or sub-document) that can be used as a field type for another model type.
It may also be used for lists,
where for example
Order.item is a list of
OrderItem embedded values.
Models to be embedded take on the field limitations of whatever type they are embedded on.
Local vs Global
Global embedded types may be used and embedded within any other type. They have a distinct name and definition file separate from other files. Because they are independent types, they may be used from any other type.
Local embedded types may only be used and embedded within a single model type. They are defined directly in the same model configuration file that uses them.
To define and use data models in your project, create a directory named "📦" in the root
of your project. This directory will contain
.yaml files that
define the model names and fields, as well as the structure of
The file name indicates both the name of the model as well as the model's type. The model's type is denoted with a specific emoji prefix.
- Universal — prefix file with 🌐
- Content — prefix file with 📄
- User Profile — prefix file with 👤
- Embedded — prefix file with 📎
To define model types that are in a container, place them into a directory named after the container type.
/📦/🌐List.yaml /📦/List/🌐Note.yaml /📦/List/🌐Task.yaml
Custom ID Prefixes
Models always have an automatically generated unique
A custom prefix may be added to all generated IDs for a particular model type.
This prefix may be between 1-3 lowercase alpha characters (a-z), and optionally end with an underscore.
🎛: prefix: prd_ # Field definitions
This will produce IDs for the
Product model such as
Field names must follow camel case, e.g. "camel" or "camelCase". All defined fields are indexed and required by default. Field definitions have a short form and long form, which may be mixed and matched as needed in the same file. .yaml files use spaces, not tabs, for indentation.
To compactly use all defaults for a field, simply assign a field type immediately following the field name (all fields are required by default).
fieldName: string otherField: boolean
Short form field definitions may be configured as
optional with the '?' postfix:
To define additional field properties use the long form:
fieldName: type: string optional: true unique: true otherField: type: boolean
Global embedded values may be referenced as any other field type:
Local embedded values have field definitions inlined beneath the
contact: type: first: string last: string email: string
This local embedded model type is ultimately accessed as:
order.contact = new Order.Contact().email('email@example.com')