Diese Seite ist Teil eines KI-Coding-Agent-Skills und für Agenten geschrieben, nicht für Menschen. Für die menschenlesbare Base44-Dokumentation siehe die Entwicklerdokumentation.

Entitäten erstellen

Base44-Entitäten werden lokal in deinem Projekt definiert und dann zum Base44-Backend gepusht.

Kritisch: Dateibenennung

Entitätsdateien MÜSSEN kebab-case-Benennung verwenden: {kebab-case-name}.jsonc

Entitätsname	Dateiname
`Task`	`task.jsonc`
`TeamMember`	`team-member.jsonc`
`ActivityLog`	`activity-log.jsonc`

FALSCH: TeamMember.jsonc, teamMember.jsonc RICHTIG: team-member.jsonc

Inhaltsverzeichnis

Entitäten erstellen

Entitätsverzeichnis

Alle Entitätsdefinitionen müssen im Ordner base44/entities/ im Projekt-Root abgelegt werden. Jede Entität wird in einer eigenen .jsonc-Datei definiert. Beispielstruktur:

my-app/
  base44/
    entities/
      user.jsonc
      product.jsonc
      order.jsonc

So erstellst du eine Entität

Erstelle eine neue .jsonc-Datei im Verzeichnis base44/entities/
Definiere dein Entitätsschema nach der Struktur unten
Pushe die Änderungen mit der CLI zu Base44

Struktur des Entitätsschemas

Jede Entitätsdatei folgt einer JSON-Schema-ähnlichen Struktur:

{
  "name": "EntityName",       // PascalCase entity name
  "type": "object",           // Always "object"
  "properties": {
    // Define your fields here
  },
  "required": ["field1"]      // Array of required field names
}

Häufiger Fehler: Verschachteltes Schema-Property

FALSCH — Umschließe Properties NICHT in einem schema-Objekt:

{
  "name": "Task",
  "description": "A task entity",
  "schema": {                    // ❌ WRONG - don't use nested "schema"
    "type": "object",
    "properties": { ... }
  }
}

RICHTIG — Platziere type und properties auf oberster Ebene:

{
  "name": "Task",
  "description": "A task entity",
  "type": "object",              // ✅ CORRECT - top level
  "properties": { ... }          // ✅ CORRECT - top level
}

Das ist ein häufiger Fehler, der beim Pushen von Entitäten den Fehler “Invalid schema: Schema must have a ‘type’ field” auslöst.

Unterstützte Feldtypen

String

Einfaches Textfeld:

{
  "title": {
    "type": "string",
    "description": "Task title"
  }
}

Mit Format:

{
  "due_date": {
    "type": "string",
    "format": "date",
    "description": "Due date"
  }
}

Verfügbare Formate: date, date-time, time, email, uri, hostname, ipv4, ipv6, uuid, file, regex, richtext

String mit Enum

Auf bestimmte Werte beschränkt:

{
  "status": {
    "type": "string",
    "enum": ["todo", "in_progress", "done"],
    "default": "todo",
    "description": "Current status"
  }
}

Number

{
  "position": {
    "type": "number",
    "description": "Position for ordering"
  }
}

Integer

Nur für ganze Zahlen:

{
  "quantity": {
    "type": "integer",
    "description": "Item quantity",
    "minimum": 0,
    "maximum": 1000
  }
}

Binary

Für Datei- oder Blob-Daten:

{
  "attachment": {
    "type": "binary",
    "description": "File attachment"
  }
}

Boolean

{
  "notify_on_change": {
    "type": "boolean",
    "default": true,
    "description": "Enable notifications"
  }
}

Array von Strings

{
  "labels": {
    "type": "array",
    "items": { "type": "string" },
    "description": "Task labels/tags"
  }
}

Array von Objekten

{
  "attachments": {
    "type": "array",
    "description": "File attachments",
    "items": {
      "type": "object",
      "properties": {
        "name": { "type": "string" },
        "url": { "type": "string" },
        "type": { "type": "string" }
      }
    }
  }
}

Feldeigenschaften

Eigenschaft	Beschreibung
`type`	Datentyp: `string`, `number`, `integer`, `boolean`, `array`, `object`, `binary`
`description`	Menschenlesbare Beschreibung des Feldes
`enum`	Array erlaubter Werte (für Strings)
`enumNames`	Menschenlesbare Labels für Enum-Werte (gleiche Reihenfolge wie `enum`)
`default`	Standardwert, wenn nicht angegeben
`format`	Formathinweis: `date`, `date-time`, `time`, `email`, `uri`, `hostname`, `ipv4`, `ipv6`, `uuid`, `file`, `regex`, `richtext`
`items`	Schema für Array-Elemente
`properties`	Verschachtelte Properties für Objekt-Typen
`$ref`	Referenz auf eine andere Schema-Definition
`minLength`	Minimale String-Länge
`maxLength`	Maximale String-Länge
`pattern`	Regex-Muster für String-Validierung
`minimum`	Minimalwert für Zahlen
`maximum`	Maximalwert für Zahlen
`rls`	Field-Level-Security-Regeln (siehe Abschnitt Field Level Security)

Vollständiges Beispiel

Hier eine vollständige Entitätsdefinition für eine Task:

{
  "name": "Task",
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "description": "Task title"
    },
    "description": {
      "type": "string",
      "description": "Task description"
    },
    "status": {
      "type": "string",
      "enum": ["todo", "in_progress", "done"],
      "default": "todo",
      "description": "Current status of the task"
    },
    "board_id": {
      "type": "string",
      "description": "Board this task belongs to"
    },
    "assignee_email": {
      "type": "string",
      "description": "Email of assigned user"
    },
    "priority": {
      "type": "string",
      "enum": ["low", "medium", "high"],
      "default": "medium",
      "description": "Task priority"
    },
    "due_date": {
      "type": "string",
      "format": "date",
      "description": "Due date"
    },
    "labels": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Task labels/tags"
    }
  },
  "required": ["title"]
}

Benennungskonventionen

Entitätsname: Verwende PascalCase mit nur alphanumerischen Zeichen (z. B. Task, TeamMember, ActivityLog)
- Muss dem Muster entsprechen: /^[a-zA-Z0-9]+$/
- Gültig: Task, TeamMember, Order123
- Ungültig: Team_Member, Team-Member, Team Member
Dateiname: Verwende kebab-case passend zur Entität (z. B. task.jsonc, team-member.jsonc, activity-log.jsonc)
Feldnamen: Verwende snake_case (z. B. board_id, user_email, due_date)

Beziehungen zwischen Entitäten

Um Beziehungen zwischen Entitäten zu erstellen, verwende ID-Referenzfelder:

{
  "board_id": {
    "type": "string",
    "description": "Board this task belongs to"
  },
  "team_id": {
    "type": "string",
    "description": "Associated team ID"
  }
}

Row Level Security (RLS)

Row Level Security (RLS) steuert, welche Datensätze Benutzer basierend auf ihrer Identität und ihren Attributen zugreifen können. RLS-Regeln werden pro Entität im Feld rls des Schemas definiert. Wichtig: Wenn kein RLS definiert ist, sind alle Datensätze für alle Benutzer zugänglich.

RLS-Operationen

RLS unterstützt fünf Operationen:

Operation	Beschreibung
`create`	Steuert, wer neue Datensätze hinzufügen kann
`read`	Steuert, wer Datensätze ansehen kann
`update`	Steuert, wer Datensätze ändern kann
`delete`	Steuert, wer Datensätze entfernen kann
`write`	Kurzform für `create`, `update` und `delete` zusammen

Berechtigungswerte

Jede Operation akzeptiert einen der folgenden Werte:

true — Alle Benutzer erlauben (einschließlich anonym/nicht authentifiziert)
false — Alle Benutzer blockieren
Bedingungsobjekt — Benutzer erlauben, die der Bedingung entsprechen

Template-Variablen

Verwende Template-Variablen, um auf Attribute des aktuellen Benutzers zu verweisen:

Template	Beschreibung
`{{user.id}}`	Die ID des Benutzers
`{{user.email}}`	Die E-Mail des Benutzers
`{{user.role}}`	Die Rolle des Benutzers
`{{user.data.field_name}}`	Benutzerdefiniertes Feld aus dem `data`-Objekt des Benutzers

Eingebaute Entitätsattribute

Jeder Entitätsdatensatz hat diese eingebauten Attribute, die für RLS-Regeln verfügbar sind:

Attribut	Beschreibung
`id`	Eindeutiger Datensatz-Identifikator
`created_date`	Zeitstempel der Erstellung des Datensatzes
`updated_date`	Zeitstempel der letzten Aktualisierung des Datensatzes
`created_by`	E-Mail des Benutzers, der den Datensatz erstellt hat

Regeltypen

Es gibt zwei Bedingungstypen, die du verwenden kannst: 1. Entitäts-zu-Benutzer-Vergleich — Vergleiche Datensatzfelder mit Werten des aktuellen Benutzers:

{
  "created_by": "{{user.email}}"
}

2. Benutzerbedingungsprüfung — Prüfe Benutzereigenschaften direkt mit user_condition:

{
  "user_condition": { "role": "admin" }
}

Wichtige Hinweise:

user_condition unterstützt nur einfache Gleichheit (z. B. { "role": "admin" })
Entitäts-Feldfilterung erfordert data.-Präfix: Verwende { "data.fieldname": value }, um nach Entitätsfeldwerten zu filtern
Für data.*-Feldvergleiche kannst du Operatoren verwenden: $in, $nin, $ne, $all
Logische Operatoren $or, $and, $nor stehen zum Kombinieren von Bedingungen zur Verfügung

⚠️ Für fortgeschrittene RLS-Muster und Beispiele siehe rls-examples.md

RLS-Beispiele

Nur-Besitzer-Zugriff:

{
  "created_by": "{{user.email}}"
}

Abteilungsbasierter Zugriff:

{
  "data.department": "{{user.data.department}}"
}

Nur-Admin-Zugriff:

{
  "user_condition": { "role": "admin" }
}

Vollständige RLS-Konfiguration:

{
  "name": "Task",
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "description": "Task title"
    },
    "status": {
      "type": "string",
      "enum": ["todo", "in_progress", "done"],
      "default": "todo"
    }
  },
  "required": ["title"],
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Häufige RLS-Muster

Öffentliches Erstellen, nur-Admin-Verwaltung (z. B. Kontaktformulare, Warteliste):

{
  "rls": {
    "create": true,
    "read": { "user_condition": { "role": "admin" } },
    "update": { "user_condition": { "role": "admin" } },
    "delete": { "user_condition": { "role": "admin" } }
  }
}

Nur-Besitzer-Zugriff:

{
  "rls": {
    "create": true,
    "read": { "created_by": "{{user.email}}" },
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Nur eingeloggte Benutzer:

{
  "rls": {
    "create": { "user_condition": { "id": "{{user.id}}" } },
    "read": true,
    "update": { "created_by": "{{user.email}}" },
    "delete": { "created_by": "{{user.email}}" }
  }
}

Einschränkungen

user_condition nur Gleichheit: user_condition unterstützt nur exakte Übereinstimmung (z. B. { "role": "admin" }) — keine Operatoren
Keine Vergleichsoperatoren bei user_condition: $gt, $lt, $regex, $expr, $where werden bei User-Bedingungen NICHT unterstützt
Keine tief verschachtelten Templates: Templates wie {{user.data.profile.department}} funktionieren möglicherweise nicht

Unterstützte Operatoren:

Logische Operatoren: $or, $and, $nor zum Kombinieren mehrerer Bedingungen
Feldoperatoren (nur für data.*-Felder): $in, $nin, $ne, $all
Entitäts-Feldfilterung: Verwende data.-Präfix, um nach Entitätsfeldwerten zu filtern (z. B. { "data.status": "published" } oder { "data.completed": true })

⚠️ Siehe rls-examples.md für umfassende RLS-Muster und Beispiele

Komplexe Zugriffsmuster

Für komplexe Zugriffsmuster, die mehrere Bedingungen erfordern (z. B. “Besitzer ODER Admin”), hast du zwei Möglichkeiten:

Base44-Dashboard-UI verwenden — Das Dashboard erlaubt das Hinzufügen mehrerer Regeln pro Operation mit ODER-Logik
Separate Entitäten verwenden — Daten in mehrere Entitäten mit unterschiedlichen Zugriffsregeln aufteilen
Backend-Funktionen verwenden — Benutzerdefinierte Zugriffslogik in Backend-Funktionen implementieren

Field Level Security (FLS)

Field Level Security erlaubt dir, den Zugriff auf einzelne Felder innerhalb einer Entität zu steuern. FLS-Regeln werden im Schema jedes Felds über die Property rls definiert.

FLS-Operationen

FLS unterstützt dieselben Operationen wie RLS auf Entitätsebene:

Operation	Beschreibung
`create`	Steuert, wer dieses Feld beim Erstellen von Datensätzen setzen darf
`read`	Steuert, wer dieses Feld ansehen darf
`update`	Steuert, wer dieses Feld ändern darf
`delete`	Steuert, wer dieses Feld leeren darf
`write`	Kurzform für `create`, `update` und `delete` zusammen

FLS-Beispiel

{
  "name": "Employee",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Employee name"
    },
    "salary": {
      "type": "number",
      "description": "Employee salary",
      "rls": {
        "read": { "user_condition": { "role": "hr" } },
        "update": { "user_condition": { "role": "hr" } }
      }
    },
    "department": {
      "type": "string",
      "description": "Department name"
    }
  },
  "required": ["name"]
}

In diesem Beispiel können nur Benutzer mit der Rolle hr das Feld salary lesen oder aktualisieren. Alle Benutzer mit Zugriff auf die Entität können andere Felder lesen/aktualisieren.

FLS-Hinweise

Wenn keine feldbasierte RLS definiert ist, erbt das Feld die Regeln auf Entitätsebene
FLS-Regeln folgen dem gleichen Bedingungsformat wie RLS auf Entitätsebene
Verwende FLS für sensible Felder wie Gehalt, SSN oder interne Notizen

Entitäten pushen

Der Befehl entities push pusht alle Entitäten, die im Ordner base44/entities existieren.

npx base44 entities push

Weitere Details zum Push-Befehl siehe entities-push.md.

Diese Seite wurde mit KI übersetzt. Für die genauesten und aktuellsten Informationen siehe die englische Version.

​Entitäten erstellen

​Kritisch: Dateibenennung

​Inhaltsverzeichnis

​Entitätsverzeichnis

​So erstellst du eine Entität

​Struktur des Entitätsschemas

​Häufiger Fehler: Verschachteltes Schema-Property

​Unterstützte Feldtypen

​String

​String mit Enum

​Number

​Integer

​Binary

​Boolean

​Array von Strings

​Array von Objekten

​Feldeigenschaften

​Vollständiges Beispiel

​Benennungskonventionen

​Beziehungen zwischen Entitäten

​Row Level Security (RLS)

​RLS-Operationen

​Berechtigungswerte

​Template-Variablen

​Eingebaute Entitätsattribute

​Regeltypen

​RLS-Beispiele

​Häufige RLS-Muster

​Einschränkungen

​Komplexe Zugriffsmuster

​Field Level Security (FLS)

​FLS-Operationen

​FLS-Beispiel

​FLS-Hinweise

​Entitäten pushen

Entitäten erstellen

Kritisch: Dateibenennung

Inhaltsverzeichnis

Entitätsverzeichnis

So erstellst du eine Entität

Struktur des Entitätsschemas

Häufiger Fehler: Verschachteltes Schema-Property

Unterstützte Feldtypen

String

String mit Enum

Number

Integer

Binary

Boolean

Array von Strings

Array von Objekten

Feldeigenschaften

Vollständiges Beispiel

Benennungskonventionen

Beziehungen zwischen Entitäten

Row Level Security (RLS)

RLS-Operationen

Berechtigungswerte

Template-Variablen

Eingebaute Entitätsattribute

Regeltypen

RLS-Beispiele

Häufige RLS-Muster

Einschränkungen

Komplexe Zugriffsmuster

Field Level Security (FLS)

FLS-Operationen

FLS-Beispiel

FLS-Hinweise

Entitäten pushen