Defaultwerte

Worum es geht

Ein Defaultwert ist der Wert, den ein Feld beim Anlegen bekommt, wenn der Client keinen schickt. Du legst ihn im Hub am Feld fest: bei einfachen Feldern als „Defaultwert“, bei Enum-Feldern als „Vorgabewert“.

Anlegen mit Defaults

Anfrage

POST /api/rest/preset/create
{ "data": { "note": "vom Client" }, "response": ["+"] }

Antwort

{
  "data": {
    "id": "3f0c…",
    "_createdOn": "2026-09-21 10:15:02",
    "_updatedOn": null,
    "label": "unnamed",
    "status": "NEW",
    "amount": 7,
    "ratio": 1.5,
    "active": true,
    "dueOn": "2026-01-01",
    "startedAt": "2026-09-21 10:15:02",
    "note": "vom Client"
  },
  "meta": { "error": false }
}

Nur note kam vom Client. Alle anderen Felder haben ihren Default bekommen, startedAt mit NOW() den Zeitpunkt des Anlegens.

Die Arten von Defaults

Es gibt zwei Arten: einen festen Wert (Literal), der immer gleich ist, und NOW(), das bei jedem Anlegen neu ausgewertet wird.

Feldtyp	fester Wert, Beispiel	`NOW()`
Text	`unnamed` (Leerzeichen am Rand werden entfernt)	–
Ganzzahl, Kommazahl	`7`, `1.5`	–
Ja/Nein	`true` oder `false`	–
Enum	Name des Werts, z. B. `NEW`	–
UUID	`3f0c1d2e-…`	–
Datum	`2026-01-01`	`NOW()` oder `LocalDate.NOW()` → heute
Uhrzeit	`08:00:00`	`NOW()` oder `LocalTime.NOW()` → jetzt
Zeitpunkt	`2026-01-01 08:00:00` oder `2026-01-01T08:00:00`	`NOW()` oder `LocalDateTime.NOW()` → jetzt

Groß- und Kleinschreibung zählt bei true/false und bei Enum-Namen nicht. Weitere Funktionen neben NOW() gibt es nicht. Beziehungen haben keinen Default, eine Referenz oder Liste ist beim Anlegen ohne Wert leer.

Wann ein Default greift

Bekommt das Feld seinen Default?

Operation	Wert im Request	Ergebnis
Anlegen	Feld fehlt	Default
Anlegen	Feld ist `null`	Default
Anlegen	Wert	Wert des Clients
PUT	Feld fehlt oder `null`	kein Default, das Feld wird geleert
PATCH	Feld fehlt	kein Default, das Feld bleibt unverändert
PATCH	Feld ist `null`	kein Default, das Feld wird geleert

„Anlegen“ heißt: Jedes Objekt, das neu entsteht. Das gilt auch für ein Kind ohne id, das in einem PUT oder PATCH seines Elternobjekts mit angelegt wird. Das Kind bekommt seine Defaults, das Elternobjekt nicht.

Der Default im Ablauf

Wo der Default beim Anlegen eingesetzt wird

1

Client→CDMS
schickt POST /preset/create mit { "note": "vom Client" }
2

CDMS
geht jedes Feld durch; ist der Wert leer und hat das Feld einen Default, setzt es ihn ein
3

Hook
Before-Hooks sehen das Objekt mit den Defaults und können sie überschreiben
4

CDMS
prüft die Regeln; ein Pflichtfeld mit Default ist damit erfüllt
5

CDMS→Database
speichert das Objekt mit den eingesetzten Werten

Weil der Default vor der Validierung eingesetzt wird, kannst du ein Feld zum Pflichtfeld machen und ihm trotzdem einen Default geben. Der Client muss es dann nicht schicken. Siehe Validierung.

Der Default lebt nur in CDMS, nicht in der Datenbank. Eine Zeile, die an der API vorbei entsteht, etwa per SQL, bekommt ihn nicht.

Ein unbrauchbarer Default

Die Hub-Oberfläche prüft beim Speichern, ob ein Default zu Ja/Nein, Ganzzahl oder Kommazahl passt, und lehnt sonst mit 400 ab. Für Text, Datum, Uhrzeit und Zeitpunkt prüft sie nicht. Passt ein Default nicht zum Feldtyp, etwa morgen bei einem Datum, passiert zur Laufzeit Folgendes:

Default passt nicht zum Feldtyp

Feld ist optionalFeld ist Pflicht

Wann: Kein Pflichtfeld.

1

CDMS
versucht, morgen in ein Datum umzuwandeln
2

CDMS
scheitert → verwirft den Default und schreibt eine Warnung ins Log
3

CDMS→Database
speichert das Objekt mit leerem Feld

Ergebnis: 200, das Feld ist null. Das passiert bei jedem Anlegen wieder.

Wann: Das Feld hat zusätzlich die Regel Pflichtfeld.

1

CDMS
verwirft den Default wie oben
2

CDMS→Client
das Feld ist leer → 422 cannot-be-null

Ergebnis: Der Client bekommt einen Validierungsfehler für ein Feld, das er gar nicht füllen musste. Schickt er einen Wert mit, geht es.

Fallen

Wie es weitergeht

Der ganze Ablauf beim Anlegen: Ein Objekt anlegen
Regeln und Pflichtfelder: Validierung
Defaults im Hub setzen: Modellieren im Hub