Collections and fields
Content in a project is organised in collections (posts, pages, products, whatever your site needs). A collection’s schema declares its fields; the schema drives the editing form in the dashboard, validation on every save, and the types GemSync generates for your code.
The six primitives
Section titled “The six primitives”| Primitive | Stores | Notes |
|---|---|---|
string | Text | Validations for length, email, URL, UUID, IP and custom rules. |
number | Numbers | Min/max and step validations. |
boolean | True/false | |
date | A timestamp | Stored as ISO 8601. |
file | An uploaded file | Up to 5 MB per file. Filename, size and content type are stored with the document. |
link | A reference to a document in another collection | The linked document travels with API responses unless you opt out with without_links. |
Modifiers
Section titled “Modifiers”required: the document won’t save without a value. Editors see a “Required field” message on the field.arrayOf: the field holds a list of values instead of one (a list of strings, files or links).translatable: the field stores one value per project language. See locales and translations.
Validations
Section titled “Validations”Fields can carry validation rules (length bounds, numeric ranges, formats such as email or URL). They run on every save, from the dashboard and from the API alike, and failures come back per field, so editors see exactly what to fix.
The primary field
Section titled “The primary field”Mark one field as primary. Its value becomes the document’s label in dashboard listings and feeds the document’s search text.
Changing a schema
Section titled “Changing a schema”Schema changes take effect immediately: the dashboard form updates and the generated types change with it. After any schema change, rerun GemSync in the codebases that consume the project so the compiler can walk you through the affected code.