Tables & Attributes
Tables and attributes are the building blocks of every Mockomat project. A table represents a domain entity — a business concept such as Customer, Order, or Product. Its attributes are the fields your mock API returns for that entity.
This page covers table creation and configuration, attribute properties, naming conventions, data mapping, and what each setting changes in the mock API.
Modelling board showing multiple table cards with attributes listed inside each card.
Tables as Domain Entities
A table in Mockomat is a domain entity declaration — a statement that a concept exists in your data model and should be queryable through your mock API. Each table gets a list operation and a detail operation (see API Design) and reads its rows from the data pool once it is mapped (see Data Sources).
Tables are displayed as cards on the modelling board. Each card shows the table name, its color and a compact list of its attributes. Relations between tables appear as lines connecting the cards.
Table Properties
| Property | Description | Notes |
|---|---|---|
| Name | The entity identifier | PascalCase, up to 64 characters, e.g. Customer |
| Description | Optional free text | Up to 255 characters; useful for team communication |
| Volume tier | How many rows the table is expected to hold | Set on the table's Volume Tier tab |
Naming Tables
Table names should be singular PascalCase nouns in the language of your business domain. A table for customers should be named Customer, not customers, customers_table, or tbl_customer.
Avoid generic names like Data, Item, or Record. Prefer specific domain terms: Invoice, ShippingAddress, ProductCategory. For a join concept, use a compound name that conveys meaning: OrderItem rather than OrderProductLink.
Description
The description is optional but recommended. A good description answers: What does this entity represent in the business domain, and what role does it play in the model?
Creating and Managing Tables
Creating a Table
Use the add button on the board toolbar to create a table card, give it a name and optionally a description, and add attributes now or later.
Creating a new table from the modelling board toolbar.
Table Operations
The menu of a table card offers:
| Operation | Description |
|---|---|
| Edit | Change name, description and volume tier. |
| Duplicate | Creates <Name> (Copy) with the same attributes. Relations are not copied, and the copy's attributes have to be bound to data again. |
| Archive | Sets the table aside without deleting it; bring it back from Archive in the account menu. |
| Delete | Moves the table with its attributes and relations to the Recycle Bin, where you can restore it. In a guest session, deleting is permanent. |
Table Limits
The number of tables per project and attributes per table depends on your plan — see Account and Plans. When a limit is reached, the app refuses the new table or attribute and tells you that you have reached your plan's limit.
Attribute Configuration
Each attribute is a field of the table and of the records your mock API returns.
Attribute Properties
| Property | Description | Effect |
|---|---|---|
| Name | Field identifier, camelCase, up to 64 characters | The field name in mock API responses |
| Type | String, Integer, Float, Boolean, ID, Text, Decimal, Date, DateTime, Timestamp, JSON, UUID or Enum | The type in exports; choose the type the data holds |
| Required | The field must have a value | Marked as required in the OpenAPI export |
| Is list | The field holds an array of the chosen type | e.g. tags |
| Unique | Values must not repeat | Stored with the model |
| Searchable | The field takes part in search | Included in the searchTerm search of list operations |
| Sortable | Stored with the model | Marks a sortable list column in code export |
| Filterable | Stored with the model | No effect on the mock API — filtering uses operation parameters |
| Mapping | Data Source or Constant; Computed only on attributes that already have it (not evaluated) | Where the value comes from (see below) |
Sorting works on any attribute bound to a data column: pass its name as sortField. To filter, define a parameter on the operation in API Design, and pass parameter values in the type the data holds — numbers without quotes, booleans as true or false.
Attribute configuration panel showing all property fields for a selected attribute.
Adding and Ordering Attributes
Attributes are added in the table editor. A new attribute needs a name and a type; the flags start switched off and the mapping starts as Data Source without a bound column. You can reorder attributes within a table; the order is the default column order of the table's view.
Naming Conventions
| Element | Convention | Examples |
|---|---|---|
| Table names | PascalCase, singular | Customer, OrderItem, ProductCategory |
| Attribute names | camelCase | firstName, totalAmount, isActive, createdAt |
| Boolean attributes | Prefix with is, has, or can | isActive, hasDiscount, canEdit |
| Date attributes | Suffix with At, Date, or On | createdAt, expiryDate, shippedOn |
| Foreign key hints | Suffix with Id | customerId, categoryId |
Avoid abbreviations. Write description instead of desc, quantity instead of qty.
Data Mapping
Every attribute reads its value through a mapping:
- Data Source (
SOURCE) — the attribute reads a column of the table's data in Mockomat's data pool. Bind the table first, then its attributes, in the Mappings pane of the board. - Constant (
CONSTANT) — a fixed value; the runtime returns it on every row, on rows of imported data and on rows composed from value pools alike. - Computed (
COMPUTED) — an expression over other fields; the runtime does not evaluate expressions, so a computed field is not part of the response. The attribute editor no longer offers Computed; an attribute that already has a Computed mapping keeps it and is marked as not evaluated.
An attribute that should stay empty can be marked No mapping needed. For the full workflow, see Data Sources & Field Mapping.
Mappings pane with the canonical table and column bindings.
What Each Setting Changes
| Setting | Mock API | Exports |
|---|---|---|
| Table name | Default operation names | Class and type names |
| Attribute name | Field name in responses | Property and field names |
| Attribute type | — (send parameter values in the type the data holds) | Column and field types |
| Required | — | Required property in the OpenAPI export |
| Searchable | Included in searchTerm | Search fields of the generated list query |
| Sortable | — | Sortable list columns in code export |
| Filterable | — | — |
| Data Source binding | The value of the imported row | — |
Attribute settings and their effect on the mock API and exports.
Practical Workflow
- Create the table with a clear, domain-aligned name.
- Add attributes for every field the entity should expose.
- Set types carefully — they decide how exports type the field; match the type of the data you bind.
- Mark searchable fields — only where consumers search.
- Map the data — bind the table and its attributes in the Mappings pane.
- Preview the result — use the runtime preview to verify that queries return the expected data.
- Iterate — adjust attributes and mappings based on the preview.
Use the play button on any table card to open the runtime preview directly from the modelling board.
Related Pages
- Modelling Board — the visual canvas where tables are positioned and connected
- Relations — how to define connections between tables
- Data Sources — binding tables and attributes to the data pool
- API Design — operations, parameters and page sizes
- Preview & Hints — validating your model with live queries