Object class properties
An Object Class represents the entity or the table, whereas Object Class Properties represents the table columns. The rows in this table are referred to as Objects, whereas the columns and the Object properties.
To add a property to an object class you can either:
Each property has a Data Type, which determines the format of the value allowed in the database. Data types include
Simple data types: Boolean, String, Integer, Float, Datetime, Duration, Internet URL, Image URL, and Rich Text
References to Object Classes. For example, the property
Contact.Company
may have Data TypeCompany
. In this case, the reference to aCompany
(theid
of theCompany
) will be saved into the database forContact.Company
.
Each property has a Property Type as either Value or Function. Most properties are values.
Values are stored in the database
Functions are calculated runtime and never stored in the database. For example, you may define a property
Full name
for the Person Object Class, with a Functionreturn Firstname + " " + Lastname
.
Additionally, if the Data Type is a reference to another Object Class or Enum, you may define the Cardinality as either One or Many.
One: This is the default. Only a single ID (for Object Class references) or Value (for Enum references) may be stored in the database for this object class property. This is used for One-to-Many or One-to-One relationships.
Many-cardinality: Example of a not-so-good use case: Project.Members may be a Many-cardinality Object Class Property
Warning
Once you have data stored in an object class, it is not recommended to change Node Name, Data Type, Cardinality or Property Type. Doing so can cause inconsistency in your data.
Built-in properties
These properties are added to each object class and the values are populated when an object is created or updated.
Built-in properties for file object classes
General properties
Data types
All properties must be assigned a data type, defining what kind of data they store.
Boolean labels
Example
You have an object class Event
with a boolean property Open for registration
. You want to display text in the UI based on the value of that property for each event.
Assign the following boolean labels:
Label True: Open for registration
Label False: Closed for registration
Label Undefined: Not yet open for registration
Data validation
We also recommend enforcing the same validation in your UI in order to provide the best possible user experience.
Best practices
The Delete Rule Cascade Delete
can remove complexity from your logic and ensure data consistency, but it should be used with caution. When an object is deleted and the rule is triggered, it will automatically delete all objects that reference the deleted object.
It is typically used when you have a structure with a parent object class and a child object class. When the parent is deleted, you also want to delete all the children. For example, you have two object classes Order and Order Line. Each order line object has a reference to an order object, its parent. In this case Cascade Delete
will ensure that when an order is deleted, all the associated order lines are deleted.
Not all parent-child relationships warrant the use of Cascade Delete
though, particularly when you want to retain history. For example, an Employee may be referenced by many Project objects as the Project owner. If the employee leaves the company and their associated object is deleted, you probably don't want to also delete all their projects which are important company records.
If you're unsure about the which rule to use, keep it set to Delete Constraint
. You can always begin by using action nodes to first delete the child objects and then delete the parent. Then, when you are confident in your data model, you can switch to deleting only the parent and using Cascade Delete
.
GDPR
Last updated