CodamAIDocs
Module

CDMS – Data

The data layer of CodamAI. A model becomes a REST API that reads, searches, writes and deletes data. It checks every request for permissions and tenant, and it logs every change.

CDMS stands for CodamAI Data Management System. In the hub you describe a data model, for example “Customer” with name, address and orders. During the build, the generator turns it into a ready-to-run Spring Boot application with REST endpoints. You plug in your own subject-area logic through hooks.

Every request to CDMS passes through the same stations:

  1. CIAS
    Filter chain
    Who is asking? For which tenant?
    ↳ no 401 / 403
  2. CDMS
    REST layer
    Is the request complete? Which fields are requested?
    ↳ no 400
  3. CDMS
    System layer
    Permissions, validation, hooks, nested objects
    ↳ no 403 / 404 / 422
  4. CDMS
    Persistence
    Which database? Which rows are visible?
    ↳ no 404 / 500
  5. Response with data and meta, the transaction is committed

The subject areas below follow this path: first the basics, then reading, searching, writing and deleting, and after that the cross-cutting topics security, tenants, audit and extension.

Subject areas

Basics: model, layers, endpoints

What a CDMS model is, on which level its data lives, which layers a request passes through, and which endpoints a model gets.

Model levels: system, tenant, userOne model, four shapesSystem fields that the server setsThe path of a request through the layersWhich endpoints a model hasSingletons: exactly one objectAbstract models and @typeThe response format: data and meta
From model to application

How a model in the hub becomes runnable code: modeling, fetching metadata, generating, project scaffold, and how schema changes run in a controlled way through the MCP server.

Modeling in the hubCode generation in the buildThe project scaffoldGenerated code and custom codeSchema change through the MCP server
Reading data

Reading an object and deciding exactly which fields and references come back: field selection, wildcards, nested references, abstract types, and what happens in the database.

Reading an objectField selection with responseWildcards + and *Expanding references and listsReading through abstract typesWhat happens in the database when reading
Searching, filtering, paging

Querying lists with POST /query: filter tree of AND/OR groups, all operators, search patterns with LIKE, paths across relations, sorting, pages, and the filters the server always adds.

Structure of a searchAll filter operatorsSearch patterns with LIKE: % and _AND/OR groupsFiltering and sorting across relationsSearching collections with MEMBEROFSortingPaging and match countFilters in nested listsDate and time valuesFilters that always run alongWhen a filter does not fit
Writing data

Creating and changing objects: create, PUT (replace) and PATCH (change), the null trap, default values, validation, and what happens with concurrent changes.

Creating an objectReplacing with PUTChanging with PATCHPUT or PATCH? The null trapDefault valuesValidationConcurrent changes
Relations and nested writing

How objects are connected to each other, and how you create, link, change or remove connected objects in the same request.

Relation types and recursive flagsThe four cases in nested writingLists as target stateBoth sides of a relationMany-to-many through a join tableCycle protection
Deleting data

How an object is deleted, what happens to dependent objects and files, and what is left afterwards.

How a DELETE runsDependent objects (cascades)Deleting by changingDeleting file modelsWhat remains after a delete
Transactions and consistency

When changes are final: one request is one transaction, commit before the response, and where atomicity ends.

One request, one transactionCreate and read back: STRICT or LENIENTNo atomicity across two databasesFiles and transactionMay the client retry?
Files

Uploading, downloading, replacing and versioning files: where the bytes live, where the metadata lives, and how both stay together.

What a file model isUploadingDownloadingReplacing and renamingFile versionsStorage layout and tenant isolation in storageSize limitsStorage backends
Data security

Who may see and change what: permissions on model, relation and row, own data, attribute filters, why invisible objects return 404, and how strict mode handles errors.

The three levels at a glanceModel rolesHow role names are builtPermissions on relations (field roles)Protected values (roles on simple fields)Encrypted fieldsOnly your own data (owner filter)Attribute filterCustom data filtersWhy invisible objects return 404Strict mode: error or silently ignoreAccess without a token
Tenant isolation in CDMS

How CDMS keeps customers apart: one database per tenant, where the tenant of a request comes from, how it is switched, and which rules are never broken.

SINGLE and MULTIWhere the tenant of a request comes fromWhich database? The persistence targetTenant switch by headerUser switch by headerIs the tenant served?Databases, pools, migrationRules that are never broken
Audit, history, rollback

How every change stays traceable: revisions, reading the history, rolling back to an old state, and what happens to files and relations along the way.

What is auditedWhat a revision recordsReading the historyRolling back to an old stateRollback for filesAudit is not the same as system fieldsData protection and retention
Plugging in your own subject-area logic

How project logic gets into the standard flows without changing generated code: hooks, their order, and how they behave on errors and with nested objects.

Hooks: types and timingField hooksThe order within a write operationHooks for nested objects and cascadesA hook writes itselfWhen a hook fails
Understanding errors

What errors look like, what each status code means and how to tell 401, 403 and 404 apart.

The error formatMap of status codes401, 403 or 404?Getting validation errors into the form
Search