Glossary
This is a collection of platform-specific terms along with their meanings, designed to provide more user-friendly alternatives to technical database terminology.
Admin / Administrator
An "Administrator" Role (with Admin access enabled) is included when you first install the platform. All admin roles bypass the permissions check, providing unrestricted access to all data within the App and API. Additionally, only roles with the admin option enabled can manage Settings within the app.
Field
Fields that don’t directly correspond to a physical database column are referred to as Fields. These include presentation fields (like dividers and groups) and certain relational types that showcase data stored in other locations, such as Many-to-One (M2O) and Many-to-Many (M2M) relations.
API
The Application Programming Interface (API) provided by the platform is how you can programmatically connect your project's content, files, and system information to external code (like a website) or with other third-party services.
Tables
Table are containers for specific types of Items and contain any number of fields. Each table represents a table in your database. By default, the title formatter is used to display any existing database table names as human-readable collection titles. There are also "folder" table that are exclusively used for organizational purposes, and don't hold any data themselves.
Table can be organized in any way that is appropriate for your project. You can architect them platform-specific (e.g., pages of a website), or in a more platform-agnostic way (e.g., raw customers of your business). While there's no right or wrong way to structure your data-model, we recommend keeping your data as agnostic as possible so it is easier to repurpose in the future. In short, learn to see your data as its own asset — not only through the lens of your immediate project needs.
The only requirement of a collection is that it must contain a Primary Key field. This field stores a unique value that is used to reference the Collection's items throughout the database/platform.
Relevant Guides
Environments
Environments (e.g., dev, staging, prod) are tracked as separate Project instances. You can then use schema/content migrations to promote data between them.
Fields
Fields are a specific type of value within a Collection, storing the data of your item's content. Each field represents a column in your database. For example, an articles Collection might have title, body, author, and date_published field. Fields mirror the characteristics of their associated column, including its name, type, default, length, allow_null, etc.
Relevant Guides
Files & Assets
Files encompass a wide range of content, including images, videos, PDFs, text documents, and more. Although files can technically be stored as code in a database, it is more practical and common to manage them as standalone assets on a “drive.” The platform offers robust support for uploading, storing, transforming, and retrieving various file types, making it an exceptional tool for Digital Asset Management (DAM).
Items
Items are objects within a Table which contain values for one or more fields. Each item represents a record in your database.
Items are the primary building blocks of your project content. Similar to a "row" within a spreadsheet, all data within the platform is accessed via these "atomic" data units. Items themselves are fairly straightforward, however their real power comes from the complexity that begins to form when items are relationally connected to each other.
Items are referenced (both individually and relationally) by their unique primary key.
Relevant Guides
Permissions
Permissions are attached directly to a Policy, defining what a user can create, read, update, and delete within the platform. Extremely granular, these filter-based permissions control access for the entire system.
Primary Key (PK)
When we're trying to view or reference a specific Item within a Table, you need some sort of unique identifier to know exactly where to look. Much like an address for a house, the primary key field provides the location of an item within its collection. For that reason, every collection must have a primary key field, and so they are configured when you create the table. There are different types of identifiers you can use, but the field is often called id.
Projects
A Project is a complete instance of the platform. Each project represents a Database, but also encapsulates a config file, asset storage, and any custom extensions. Projects are the highest level of organization in Ucode.
Relations
The platform allows you to group Items within different Table. But often times it is important to "link" items across different tables (such as relating recipes and ingredients) — this is called a relation, a crucial concept within any relational database. There are several different types of relations, each serving a specific purpose. Learn more about Relationships.
Roles
Roles define a specific set of Policies, and are the primary organizational structure for Users within the platform. You can create an unlimited number of roles, so organize your users in whatever way feels most appropriate.
Roles can also contain any number of additional roles, each containing their own set of Policies.
During the installation process, Ucode automatically creates an "Administrators" Role, which is used to provide the initial admin user with full platform access. However this is just a normal role, and so it can still be updated, renamed, or even deleted. Keep in mind that your project must maintain at least one role with Admin Access at all times.
There is also a "Public" role that determines access for unauthenticated access.
Users
An active User is required to access a project. Each user is assigned to a Role that determines their policies what they have access to see and do. This means that the experience of users may vary significantly depending on their role's permissions. Users can also have policies directly attached to them.
Last updated