Object classes
To store data in a solution you need to create object classes to describe the types of data you'd like to store. It is common to set up some foundational object classes with a few initial properties as the first step in a new solution. Object classes are defined in the Global data model and are exposed to the apps and services in your solution using data sources.
Usage
To add an object class to your data model:
Hover over the + icon in the bottom-right of the data model designer.
Click Create Object Class.
An object class is a structured definition of a single business object, for example a Project. Each object class is assigned properties which are individual fields for storing data, such as Title, Status, or Created Date. Each property has a data type, such as string, boolean, or datetime which determines the format of the value allowed in the database. Object classes can also reference each other, allowing you to connect a Task to a Project.
Best practice
Use the singular when naming an object class (Project, not Projects) since it does not contain any data but is a definition of how a single object is structured.
To read and modify objects in an object class you must first create a data source in an app or service. You can then use action nodes to create an object within an object class, assign values to the properties you have defined, and persist (store) the data in the database.
Good to know
Every solution has one built-in object class called User. This object class represents the users of your apps. The User object class cannot be modified, but it can be referenced in the same way as any other object class.
File object class
To store files such as documents and images in the database, there is a special type of object class called a File object class. For example, PDFs created using the Generate document action node or files and images uploaded by end-users should be stored in file object classes. For static files used in your apps, you should use Files.
To add a file object class to your data model:
Hover over the + icon in the bottom-right of the data model designer.
Click Create File Object Class.
File object classes have additional built-in properties to store file metadata.
General properties
These general properties describe an object class and are not to be confused with object class properties that are used to store data.
| Property | Description |
|---|---|
Name | A descriptive name for the object class. Use the singular (Project, not Projects). |
Display Property | |
Description | A longer description of the object class. For your own reference. |
Icon | An icon from the built-in icon library to represent the object class throughout Appfarm Create. |
Tags |
Meta Data
You can enable additional built-in object class properties. When any of the properties below are enabled, these properties will be stored for each new record.
| Property | Description |
|---|---|
Created By | Add a read-only property to every object with a reference to the User that created the object. |
Updated By | Add a read-only property to every object with a reference to the User that last updated the object. |
Random Identifier | Add a read-only string property to every object with an automatically generated unique, random identifier. |
Sequential Identifier | This will generate a sequential identifier on each object (often also referred to as a sequential counter). The value will be set when the object is stored in the database. That is, when persisting a runtime object or creating an object in a database connected data source.
Example: The Object Class |
Starting Value | Only applicable when Sequential Identifier is enabled. This is the starting value of the Sequential Identifier. The default is 1, but you may choose a higher starting value (for example, if you want to generate order numbers starting at 10000, you may set Starting Value to 10000) |
Concurrency Control
By default, when 2 different users update the same object, the last write wins.
Users John and Paula both read company ThirtyFifty Inc into a runtime only data source.
John updates the Status to
Inactive, Paula updates the Status toProspect. Both at the same time. The changes has not yet been saved.John clicks Save. The entry in the database is updated to
Inactive.Paula clicks Save. The same entry is the database is updated to
Prospect.
The outcome: ThirtyFifty Inc's Status is updated to Prospect. The last write (Paula) wins.
The built-in Object Class Property Strict Object Versioning allows you to enable first write wins.
Users John and Paula both read company ThirtyFifty Inc into a runtime only data source.
John updates the Status to
Inactive, Paula updates the Status toProspect. Both at the same time. The changes has not yet been saved.John clicks Save. The entry in the database is updated to
Inactive.Paula clicks Save. An exception is thrown (ConflictError (34013)), and the entry is not updated.
The outcome: ThirtyFifty Inc's Status is updated to Inactive. The first write (John) wins.
Enabling Strict Object Versioning also enables a built-in integer property Version No for the objects of this Object Class. The Version No is automatically incremented every time the object is successfully updated.
Please note
It is not recommended to use Subscribe to updates with Strict Object Versioning since this might break the strict versioning control.
Components dispatching frequently updates might not work in conjunction with Strict Object Versioning as subsequent updates might be dispatched with the old version number.
Data connectors or updates using GraphQL cannot be used in conjunction with Strict Object Versioning .
GraphQL
Exposure of an object class via GraphQL must be explicitly enabled. The specific types of queries and mutations that should be available must also be enabled.
In addition to these properties, to successfully run those queries and mutations, you need to have a role with the appropriate permissions, and GraphQL must be enabled for the environment.
| Property | Description |
|---|---|
Enable GraphQL | Expose this object class via a GraphQL endpoint. |
Endpoint Name | The name of the GraphQL endpoint. This is generated automatically based on the Collection Name of the object class. Warning: If the GraphQL endpoint is used in Production and this name is changed, existing queries will need to be altered. |
Enable Read | |
Enable Aggregate | |
Enable Create | |
Enable Update | |
Enable Delete |
GDPR
To maintain an overview of the personal information you are storing, you can assign a GDPR classification and describe why this information is collected and stored and how this information is used. Please refer to your subscription agreement for further information about your obligations around data privacy.
| Property | Description |
|---|---|
GDPR Classification | A privacy classification for the data stored in this property. The options are:
|
GDPR Details | A description of why this information is collected and stored and how it is used. For your own reference. |
Permissions
Object class permissions form a key part of your solutions' security. They determine which roles can access and modify data in that object class. By default, the built-in roles Owners, Maintainers, and Developers get full read and write access to each object class when it's created.
When editing an object class you can grant and revoke permissions for the built-in roles as well as for each custom role. You can also edit these rules for all object classes under Permissions. Changes to object class permissions require a deploy to come into effect in an environment.
| Permission | Description |
|---|---|
Create | Create a new object in this object class. |
Read | Read data within objects in this object class. |
Update | Update (edit) data within objects in this object class. |
Delete | Delete objects in this object class. |
Aggregate |
Object class properties
See article Object class properties.
Last updated
