Modeling in the hub

What this is about

Before there is code, there is a model. In the hub you describe which things your application knows (customer, order, invoice), which fields they have, how they are connected and who may do what. Later the build generates all the code from this description, see Code generation in the build.

So you model here, you do not program. Everything you define is data in the hub: the metadata of your application.

The meta model

This is how the things you create in the hub fit together:

flowchart TD
    P["Project"] --> S["System<br/>(one CDMS application)"]
    S --> F["Folder"]
    S --> E["Enumeration"]
    S --> M["Model"]
    F -. "contains" .-> M
    F -. "contains" .-> E
    E --> EI["Enum value"]
    M --> FD["Field"]
    M --> EP["Endpoint"]
    M --> R["Role"]
    M --> AF["Access filter"]
    M --> H["Hook"]
    M -. "inherits from" .-> AM["abstract model"]
    FD --> RU["Rule"]
    FD --> FR["Field role"]
    FD -. "enum field" .-> E
    FD -. "relation field" .-> M

Three kinds of models

A model can inherit from only one abstract model. More in Abstract models, Singleton and The file model.

For each model you also define:

Fields

Every field is one of three kinds:

In the hub a relation is always a pair of fields. If you add the field customer to Order (MANY_TO_ONE to Customer), the opposite field with the reverse type (ONE_TO_MANY) appears on Customer. Both are saved in one transaction. If you delete one side, the hub deletes the other one too.

Some fields you never create yourself, because every model already has them: id, _createdOn, _updatedOn and, depending on the level, _userId. See System fields.

Rules on the field

Rules say which values a field may take. CDMS checks them when writing, see Validation.

The maximum length of a text is not a rule. It is the length property of the field.

You can limit some rules to a scope: ALWAYS (default), only CREATE or only UPDATE. This works for “not empty”, “pattern” and “minimum / maximum value”. For the required field, the operation is already part of the rule itself.

Endpoints and roles

In the Endpoints tab you define which operations exist for the model. The UI always offers the five basic operations (CREATE, READ, UPDATE, DELETE, LIST). The history endpoints exist only for audited models, UPLOAD and DOWNLOAD only for file models. What each type generates in the code is described in Which endpoints a model has.

In the Permissions tab you mark which operations require a role of their own. You only set one checkbox per operation. The generator builds the role name from folder, model and operation using a fixed pattern. In the same way there are field roles on a single field. See Model roles, Field roles and Role names.

In the Filters tab you connect a profile attribute of the user to a field. Then everyone sees only the rows whose field matches their attribute, see Attribute filter.

Which rules the hub enforces

When you save, the hub checks your input. A violation is rejected, and the UI shows you the reason at the field.

The hub calculates the path of a folder itself. If you rename or move a folder, it updates the paths of the whole subtree.

Some things are allowed but are usually a mistake. For these, the UI shows a warning sign at the field:

Checklist: a new model

Instead of doing it by hand, an AI client can also change the model, through the hub’s MCP server.

Pitfalls