What this is about
A create does not just answer “ok”, but with the created object, the way you requested it in response. To do that, CDMS reads the object back after saving it, with your permissions and filters, exactly like a normal read.
This read-back can fail even though the create succeeded. For example:
- You lack the read role of the model. You may create, but not read.
- The new object is filtered out by your row filters. For example, you create an order for a company that your attribute filter does not show you.
- A READ hook throws an error while reading.
What happens then is decided by the CreateReadMode: STRICT or LENIENT.
The two modes
When: Default. Create and read-back in one transaction.
-
1CDMS→Databasecreates the object, hooks, flush
-
2CDMS→Databasereads it back, in the same transaction
-
3CDMSreading back fails, e.g. read role missing
-
4CDMS→Clienterror of the read, e.g. 403
missing-permission|order-read; the create is rolled back
Result: There is no new object. The response describes why reading failed.
When: Create and read-back in two transactions.
-
1CDMS→Databasecreates the object, hooks, flush
-
2CDMS→Databasecommit: the object is now permanently saved
-
3CDMS→Databasereads it back, in a new transaction
-
4CDMSreading back fails
-
5CDMS→Client200 in error form,
messageKeyCDMS_CREATE_SUCCEEDED_READ_FAILEDand theidof the new object
Result: The object exists. You know its id, but you do not get its fields.
If reading back succeeds, both modes behave the same: 200 with the object.
The response with LENIENT
POST /api/rest/order/create
{
"data": { "orderNr": "A-1000", "companyId": "123456" },
"response": ["id", "orderNr"],
"createReadMode": "LENIENT"
}{
"error": "CreateSucceededReadFailedException",
"messageKey": "CDMS_CREATE_SUCCEEDED_READ_FAILED",
"code": "200",
"layer": "system",
"id": "5a2b…"
}The response has status 200, but the shape of an error response: no data, instead error, messageKey and id. So for a create, do not check only the status, but also whether data is there. See The response format: data and meta.
Choosing the mode
createReadMode in the request | Setting of the installation | Mode |
|---|---|---|
LENIENT | – | LENIENT |
STRICT | – | STRICT |
| missing | LENIENT | LENIENT |
| missing | STRICT or not set | STRICT |
- Per request:
"createReadMode": "LENIENT"in the body, next todataandresponse. This applies toPOST /create,/create/uploadand creating through the hub API of an abstract model. - For the whole installation: the setting
codamai.cdms.api.create-read-modein the application’s configuration, defaultSTRICT. - Singletons always read back in
STRICTmode when created.
For PUT, PATCH and rollback there is no choice: there, writing and reading back always belong to one transaction.
When which mode fits
- the client gets either the object or an error
- no object that its creator cannot see
- fits almost all forms
- the create should stay even if the creator may not read it
- example: a contact form, a report, an upload into an inbox
- the client must be able to handle 200 without
data
Pitfalls
What comes next
- The bracket around a request: One request, one transaction
- How a request creates: Creating an object
- The shape of responses: The response format:
dataandmeta