AWS DynamoDB

AWS DynamoDB MCP Server

Der offizielle Developer-Experience-MCP-Server für Amazon DynamoDB. Dieser Server bietet fachkundige Designberatung und Unterstützung bei der Datenmodellierung für DynamoDB.

[!IMPORTANT] Generative KI kann Fehler machen. Sie sollten in Betracht ziehen, alle von Ihrem gewählten KI-Modell und agentischen Coding-Assistenten generierten Ausgaben zu überprüfen. Siehe AWS Responsible AI Policy.

Verfügbare Werkzeuge

Der DynamoDB MCP-Server stellt acht Werkzeuge für Datenmodellierung, Validierung, Kostenanalyse und Codegenerierung bereit:

• dynamodb_data_modeling – Ruft den vollständigen DynamoDB-Datenmodellierungs-Experten-Prompt mit Designmustern auf Unternehmensebene, Kostenoptimierungsstrategien und der Multi-Table-Design-Philosophie ab. Führt durch Anforderungserfassung, Zugriffsmusteranalyse und Schemaentwurf.

  Beispielaufruf: „Entwirf ein Datenmodell für meine E-Commerce-Anwendung mit dem DynamoDB-Datenmodellierungs-MCP-Server“

• dynamodb_data_model_validation – Validiert Ihr DynamoDB-Datenmodell, indem dynamodb_data_model.json geladen, DynamoDB Local eingerichtet, Tabellen mit Testdaten erstellt und alle definierten Zugriffsmuster ausgeführt werden. Speichert detaillierte Validierungsergebnisse in dynamodb_model_validation.json.

  Beispielaufruf: „Validiere mein DynamoDB-Datenmodell“

• source_db_analyzer – Analysiert bestehende Datenbanken (MySQL, PostgreSQL, SQL Server, Oracle), um die Schemastruktur und Zugriffsmuster zu extrahieren, und generiert zeitgestempelte Analysedateien zur Verwendung mit dynamodb_data_modeling. Unterstützt sowohl RDS Data API-basierten Zugriff als auch verbindungsbasierten Zugriff für MySQL.

  Beispielaufruf: „Analysiere meine MySQL-Datenbank und hilf mir, ein DynamoDB-Datenmodell zu entwerfen“

• generate_resources – Generiert verschiedene Ressourcen aus der DynamoDB-Datenmodell-JSON-Datei (dynamodb_data_model.json). Derzeit wird nur der Ressourcentyp cdk unterstützt. Die Übergabe von cdk als resource_type-Parameter generiert eine CDK-App zur Bereitstellung von DynamoDB-Tabellen. Die CDK-App liest die dynamodb_data_model.json, um Tabellen mit der richtigen Konfiguration zu erstellen.

  Beispielaufruf: „Generiere die Ressourcen, um mein DynamoDB-Datenmodell mit CDK bereitzustellen“

• dynamodb_data_model_schema_converter – Konvertiert Ihr Datenmodell (dynamodb_data_model.md) in eine strukturierte schema.json-Datei, die Ihre DynamoDB-Tabellen, Indizes, Entitäten, Felder und Zugriffsmuster repräsentiert. Dieses maschinenlesbare Format wird für die Codegenerierung verwendet und kann für andere Zwecke wie Dokumentationsgenerierung oder Infrastrukturbereitstellung erweitert werden. Validiert das Schema automatisch mit bis zu 8 Iterationen, um Korrektheit sicherzustellen.

  Beispielaufruf: „Konvertiere mein Datenmodell zur Codegenerierung in schema.json“

• dynamodb_data_model_schema_validator – Validiert schema.json-Dateien auf Kompatibilität für die Codegenerierung. Überprüft Feldtypen, Operationen, GSI-Zuordnungen, Pattern-IDs und liefert detaillierte Fehlermeldungen mit Korrekturvorschlägen. Stellt sicher, dass Ihr Schema für das generate_data_access_layer-Werkzeug bereit ist.

  Beispielaufruf: „Validiere meine schema.json-Datei unter /pfad/zur/schema.json“

• generate_data_access_layer – Generiert typsicheren Python-Code aus schema.json, einschließlich Entitätsklassen mit Feldvalidierung, Repository-Klassen mit CRUD-Operationen, vollständig implementierten Zugriffsmustern und optionalen Nutzungsbeispielen. Der generierte Code verwendet Pydantic zur Validierung und boto3 für DynamoDB-Operationen.

  Beispielaufruf: „Generiere Python-Code aus meiner schema.json“

• compute_performances_and_costs – Berechnet DynamoDB-Kapazitätseinheiten (RCU/WCU) und monatliche Kosten aus Zugriffsmustern. Analysiert alle DynamoDB-Operationen (GetItem, Query, Scan, PutItem, UpdateItem, DeleteItem, BatchGetItem, BatchWriteItem, TransactGetItems, TransactWriteItems), verfolgt zusätzliche GSI-Schreibvorgänge und berechnet Speicherkosten. Hängt einen umfassenden Kostenbericht an dynamodb_data_model.md an.

  Beispielaufruf: „Berechne die Kosten und Leistung für mein DynamoDB-Datenmodell“

Voraussetzungen

1. Installieren Sie uv von Astral oder der GitHub README
2. Installieren Sie Python mit uv python install 3.10
3. Richten Sie AWS-Anmeldeinformationen mit Zugriff auf AWS-Services ein

Installation

Kiro	Cursor	VS Code

Hinweis: Die obigen Installationsschaltflächen konfigurieren AWS_REGION standardmäßig auf us-west-2. Aktualisieren Sie diesen Wert nach der Installation in Ihrer MCP-Konfiguration, falls Sie eine andere Region benötigen.

Fügen Sie den MCP-Server zu Ihrer Konfigurationsdatei hinzu (für Kiro zu .kiro/settings/mcp.json hinzufügen – siehe Konfigurationspfad):

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Windows-Installation

Für Windows-Benutzer ist das Konfigurationsformat des MCP-Servers geringfügig anders:

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "disabled": false,
      "timeout": 60,
      "type": "stdio",
      "command": "uv",
      "args": [
        "tool",
        "run",
        "--from",
        "awslabs.dynamodb-mcp-server@latest",
        "awslabs.dynamodb-mcp-server.exe"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

Docker-Installation

Nach einem erfolgreichen docker build -t awslabs/dynamodb-mcp-server .:

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--env",
        "FASTMCP_LOG_LEVEL=ERROR",
        "awslabs/dynamodb-mcp-server:latest"
      ],
      "env": {},
      "disabled": false,
      "autoApprove": []
    }
  }
}

Datenmodellierung

Datenmodellierung in natürlicher Sprache

Verwenden Sie das dynamodb_data_modeling-Werkzeug, um DynamoDB-Datenmodelle durch Konversation in natürlicher Sprache mit Ihrem KI-Agenten zu entwerfen. Fragen Sie einfach: „Verwende meinen DynamoDB MCP, um mir beim Entwurf eines DynamoDB-Datenmodells zu helfen.“

Das Werkzeug bietet einen strukturierten Workflow, der Anwendungsanforderungen in DynamoDB-Datenmodelle übersetzt:

Phase der Anforderungserfassung:

• Erfasst Zugriffsmuster durch Konversation in natürlicher Sprache
• Dokumentiert Entitäten, Beziehungen und Lese-/Schreibmuster
• Zeichnet geschätzte Anfragen pro Sekunde (RPS) für jedes Muster auf
• Erstellt die Datei dynamodb_requirements.md, die in Echtzeit aktualisiert wird
• Identifiziert Muster, die besser für andere AWS-Services geeignet sind (OpenSearch für Textsuche, Redshift für Analytik)
• Kennzeichnet besondere Designüberlegungen (z. B. massive Fan-Out-Muster, die DynamoDB Streams und Lambda erfordern)

Entwurfsphase:

• Generiert optimierte Tabellen- und Indexentwürfe
• Erstellt dynamodb_data_model.md mit detaillierter Entwurfsbegründung
• Liefert geschätzte monatliche Kosten
• Dokumentiert, wie jedes Zugriffsmuster unterstützt wird
• Enthält Optimierungsempfehlungen für Skalierung und Leistung

Das Werkzeug wird durch fachmännisch entwickelten Kontext unterstützt, der Reasoning-Modelle dabei unterstützt, Sie durch fortgeschrittene Modellierungstechniken zu führen. Die besten Ergebnisse werden mit Reasoning-fähigen Modellen wie Anthropic Claude 4/4.5 Sonnet, OpenAI o3 und Google Gemini 2.5 erzielt.

Datenmodellvalidierung

Voraussetzungen für die Datenmodellvalidierung: Um das Datenmodellvalidierungs-Werkzeug zu verwenden, benötigen Sie eines der folgenden:

• Container-Laufzeitumgebung: Docker, Podman, Finch oder nerdctl mit einem laufenden Daemon
• Java-Laufzeitumgebung: Java JRE Version 17 oder neuer (setzen Sie JAVA_HOME oder stellen Sie sicher, dass java in Ihrem System-PATH ist)

Verwenden Sie nach Abschluss Ihres Datenmodellentwurfs das dynamodb_data_model_validation-Werkzeug, um Ihr Datenmodell automatisch gegen DynamoDB Local zu testen. Das Validierungswerkzeug schließt die Lücke zwischen Generierung und Ausführung, indem es einen iterativen Validierungszyklus erstellt.

So funktioniert es:

Das Werkzeug automatisiert den traditionellen manuellen Validierungsprozess:

1. Einrichtung: Startet die DynamoDB-Local-Umgebung (Docker/Podman/Finch/nerdctl oder Java-Fallback)
2. Testspezifikation generieren: Erstellt dynamodb_data_model.json mit einer Auflistung von Tabellen, Beispieldaten und zu testenden Zugriffsmustern
3. Schema bereitstellen: Erstellt Tabellen, Indizes und fügt lokal Beispieldaten ein
4. Tests ausführen: Führt alle in Ihren Zugriffsmustern definierten Lese- und Schreiboperationen aus
5. Ergebnisse validieren: Überprüft, ob sich jedes Zugriffsmuster korrekt und effizient verhält
6. Iterative Verfeinerung: Falls die Validierung fehlschlägt (z. B. eine Abfrage aufgrund eines falsch ausgerichteten Partitionsschlüssels unvollständige Ergebnisse liefert), zeichnet das Werkzeug das Problem auf, generiert das betroffene Schema neu und führt die Tests erneut aus, bis alle Muster erfolgreich sind

Validierungsausgabe:

• dynamodb_model_validation.json: Detaillierte Validierungsergebnisse mit Musterantworten
• validation_result.md: Zusammenfassung des Validierungsprozesses mit Bestanden/Nicht-bestanden-Status für jedes Zugriffsmuster
• Identifiziert Probleme wie falsche Schlüsselstrukturen, fehlende Indizes oder ineffiziente Abfragemuster

Quelldatenbankanalyse

Das source_db_analyzer-Werkzeug extrahiert Schema und Zugriffsmuster aus Ihrer bestehenden Datenbank, um den Entwurf Ihres DynamoDB-Modells zu unterstützen. Dies ist nützlich bei der Migration von relationalen Datenbanken.

Das Werkzeug unterstützt zwei Verbindungsmethoden für MySQL:

• RDS Data API-basierter Zugriff: Serverlose Verbindung mittels Cluster-ARN
• Verbindungsbasierter Zugriff: Traditionelle Verbindung mittels Hostname/Port

Unterstützte Datenbanken:

• MySQL / Aurora MySQL
• PostgreSQL
• SQL Server
• Oracle

Ausführungsmodi:

• Self-Service-Modus: SQL-Abfragen generieren, selbst ausführen, Ergebnisse bereitstellen (MySQL, PostgreSQL, SQL Server, Oracle)
• Verwalteter Modus: Direkte Verbindung über AWS RDS Data API (nur MySQL)

Wir empfehlen, dieses Werkzeug gegen eine Nicht-Produktionsdatenbankinstanz auszuführen.

Self-Service-Modus (MySQL, PostgreSQL, SQL Server, Oracle)

Der Self-Service-Modus ermöglicht es Ihnen, jede Datenbank ohne AWS-Konnektivität zu analysieren:

1. Abfragen generieren: Das Werkzeug schreibt SQL-Abfragen (basierend auf der ausgewählten Datenbank) in eine Datei
2. Abfragen ausführen: Sie führen die Abfragen gegen Ihre Datenbank aus
3. Ergebnisse bereitstellen: Das Werkzeug parst die Ergebnisse und generiert die Analyse

Verwalteter Modus (nur MySQL)

Der verwaltete Modus ermöglicht es Ihnen, das Werkzeug mit der AWS RDS Data API zu verbinden, um bestehende MySQL/Aurora-Datenbanken zu analysieren und Schema und Zugriffsmuster für die DynamoDB-Modellierung zu extrahieren.

Voraussetzungen für die MySQL-Integration (Verwalteter Modus)

Für RDS Data API-basierten Zugriff:

1. MySQL-Cluster mit aktivierter RDS Data API
2. In AWS Secrets Manager gespeicherte Datenbankanmeldeinformationen
3. AWS-Anmeldeinformationen mit Berechtigungen für den Zugriff auf RDS Data API und Secrets Manager

Für verbindungsbasierten Zugriff:

1. Von Ihrer Umgebung aus erreichbarer MySQL-Server

2. In AWS Secrets Manager gespeicherte Datenbankanmeldeinformationen

3. Das Secrets-Manager-Geheimnis muss ein host-Feld enthalten, das mit Ihrem Datenbank-Hostnamen übereinstimmt (zusätzlich zu username und password). Dies stellt sicher, dass Anmeldeinformationen nur mit dem vorgesehenen Datenbank-Host verwendet werden. RDS-verwaltete Geheimnisse enthalten dieses Feld automatisch. Falls Sie Ihr Geheimnis manuell erstellt haben, stellen Sie sicher, dass es der Standardstruktur folgt:

   aws secretsmanager create-secret \
       --name "my-db-secret" \
       --secret-string '{
           "engine": "mysql",
           "host": "my-db.cluster-xxx.us-east-1.rds.amazonaws.com",
           "username": "<username>",
           "password": "<password>",
           "dbname": "<database name>",
           "port": 3306
       }'
   

4. AWS-Anmeldeinformationen mit Berechtigungen für den Zugriff auf Secrets Manager

Für beide Verbindungsmethoden: 4. Aktivieren Sie das Performance Schema für die Zugriffsmusteranalyse (optional, aber empfohlen):

• Setzen Sie den Parameter performance_schema in Ihrer DB-Parametergruppe auf 1
• Starten Sie die DB-Instanz nach den Änderungen neu
• Überprüfen mit: SHOW GLOBAL VARIABLES LIKE '%performance_schema'
• Erwägen Sie die Optimierung von:
  • performance_schema_digests_size – Maximale Zeilen in events_statements_summary_by_digest
  • performance_schema_max_digest_length – Maximale Byte-Länge pro Statement Digest (Standard: 1024)
• Ohne Performance Schema basiert die Analyse nur auf dem Information Schema

MySQL-Umgebungsvariablen

Fügen Sie diese Umgebungsvariablen hinzu, um die MySQL-Integration zu aktivieren:

Für RDS Data API-basierten Zugriff:

• MYSQL_CLUSTER_ARN: MySQL-Cluster-ARN
• MYSQL_SECRET_ARN: ARN des Geheimnisses, das die Datenbankanmeldeinformationen enthält
• MYSQL_DATABASE: Zu analysierender Datenbankname
• AWS_REGION: AWS-Region des Clusters

Für verbindungsbasierten Zugriff:

• MYSQL_HOSTNAME: MySQL-Server-Hostname oder -Endpunkt
• MYSQL_PORT: MySQL-Server-Port (optional, Standard: 3306)
• MYSQL_SECRET_ARN: ARN des Geheimnisses, das die Datenbankanmeldeinformationen enthält
• MYSQL_DATABASE: Zu analysierender Datenbankname
• AWS_REGION: AWS-Region, in der sich Secrets Manager befindet

Allgemeine Optionen:

• MYSQL_MAX_QUERY_RESULTS: Maximale Zeilen in Analyseausgabedateien (optional, Standard: 500)

Hinweis: Explizite Werkzeugparameter haben Vorrang vor Umgebungsvariablen. Es sollte nur eine Verbindungsmethode (Cluster-ARN oder Hostname) angegeben werden.

MCP-Konfiguration mit MySQL

Für RDS Data API-basierten Zugriff:

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-west-2",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "MYSQL_CLUSTER_ARN": "arn:aws:rds:$REGION:$ACCOUNT_ID:cluster:$CLUSTER_NAME",
        "MYSQL_SECRET_ARN": "arn:aws:secretsmanager:$REGION:$ACCOUNT_ID:secret:$SECRET_NAME",
        "MYSQL_DATABASE": "<DATABASE_NAME>",
        "MYSQL_MAX_QUERY_RESULTS": "500"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Für verbindungsbasierten Zugriff:

{
  "mcpServers": {
    "awslabs.dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-west-2",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "MYSQL_HOSTNAME": "<MYSQL_HOST>",
        "MYSQL_PORT": "3306",
        "MYSQL_SECRET_ARN": "arn:aws:secretsmanager:$REGION:$ACCOUNT_ID:secret:$SECRET_NAME",
        "MYSQL_DATABASE": "<DATABASE_NAME>",
        "MYSQL_MAX_QUERY_RESULTS": "500"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Verwendung der Quelldatenbankanalyse

1. Führen Sie source_db_analyzer für Ihre Datenbank aus (Self-Service- oder Managed-Modus)
2. Überprüfen Sie den generierten, mit Zeitstempel versehenen Analyseordner (database_analysis_YYYYMMDD_HHMMSS)
3. Lesen Sie zuerst die Datei manifest.md – sie listet alle Analysedateien und Statistiken auf
4. Lesen Sie alle Analysedateien, um die Schemastruktur und Zugriffsmuster zu verstehen
5. Verwenden Sie die Analyse mit dynamodb_data_modeling, um Ihr DynamoDB-Schema zu entwerfen

Das Tool generiert Markdown-Dateien mit:

• Schemastruktur (Tabellen, Spalten, Indizes, Fremdschlüssel)
• Zugriffsmustern aus dem Performance Schema (Abfragemuster, RPS, Häufigkeiten)
• Zeitgestempelter Analyse zur Nachverfolgung von Änderungen im Zeitverlauf

Schema-Konvertierung und Code-Generierung

Nachdem Sie Ihr DynamoDB-Datenmodell entworfen haben, können Sie es in ein strukturiertes Schema konvertieren und Python-Referenzcode generieren. Bei Verwendung der MCP-Tools über ein LLM erfolgt dieser gesamte Workflow automatisch – das LLM führt Sie durch Schema-Konvertierung, Validierung und Code-Generierung in einer einzigen Konversation, ohne dass manuelle Tool-Aufrufe erforderlich sind.

Für die eigenständige Nutzung können Sie diese Tools auch direkt über die CLI aufrufen oder schema.json-Dateien manuell bearbeiten und Code bei Bedarf neu generieren.

Hinweis: Die Datenmodellvalidierung (dynamodb_data_model_validation) ist für die Code-Generierung optional. Wenn Sie jedoch planen, den generierten Code mit usage_examples.py gegen DynamoDB Local zu testen, wird empfohlen, zuerst die Validierung auszuführen, da sie automatisch die Tabellen und Testdaten in DynamoDB Local einrichtet.

Datenmodell in Schema konvertieren

Das Tool dynamodb_data_model_schema_converter konvertiert Ihr menschenlesbares Datenmodell (dynamodb_data_model.md) in ein strukturiertes JSON-Schema, das Ihre DynamoDB-Tabellen, Indizes, Entitäten und Zugriffsmuster repräsentiert. Dieses maschinenlesbare Format ermöglicht die Code-Generierung und kann für Dokumentation oder Infrastrukturbereitstellung erweitert werden.

Das Tool validiert das generierte Schema automatisch und liefert detaillierte Fehlermeldungen und Korrekturvorschläge, falls die Validierung fehlschlägt. Die Ausgabe wird zur Isolierung in einem mit Zeitstempel versehenen Ordner gespeichert.

Schemastruktur:

Die generierte schema.json ist eine strukturierte Repräsentation, die Folgendes enthält:

• Tabellen: Eine oder mehrere DynamoDB-Tabellendefinitionen mit Partitions-/Sortierschlüsseln
• GSI-Definitionen: Konfigurationen für Globale Sekundärindizes (optional)
• Entitäten: Domänenmodelle (Benutzer, Bestellung, Produkt usw.) mit typisierten Feldern
• Feldtypen: string, integer, decimal, boolean, array, object, uuid
• Zugriffsmuster: Query/Scan/GetItem-Operationen mit Parameterdefinitionen und Schlüsselvorlagen
• Schlüsselvorlagen: Muster zur Generierung von Partitions- und Sortierschlüsseln (z. B. USER#{user_id})

Dieses strukturierte Format dient als Eingabe für Code-Generierungstools.

Schema-Dateien validieren

Das Tool dynamodb_data_model_schema_validator validiert Ihre schema.json-Datei, um sicherzustellen, dass sie für die Code-Generierung korrekt formatiert ist.

Validierungsprüfungen:

• Erforderliche Abschnitte (table_config, entities) sind vorhanden
• Alle erforderlichen Felder sind vorhanden
• Feldtypen sind gültig (string, integer, decimal, boolean, array, object, uuid)
• Enum-Werte sind korrekt (Operationstypen, Rückgabetypen)
• Muster-IDs sind über alle Entitäten hinweg eindeutig
• GSI-Namen stimmen zwischen gsi_list und gsi_mappings überein
• In Vorlagen referenzierte Felder existieren in den Entitätsfeldern
• Bereichsbedingungen sind gültig mit korrekten Parameteranzahlen
• Zugriffsmuster haben gültige Operationen und Rückgabetypen

Sicherheit:

Schema-Dateien müssen sich im aktuellen Arbeitsverzeichnis oder in Unterverzeichnissen befinden. Pfad-Traversal-Versuche werden aus Sicherheitsgründen blockiert.

Beispiele für die Validierungsausgabe:

Erfolg:

✅ Schema validation passed!

Fehler mit Vorschlägen:

❌ Schema validation failed:
  • entities.User.fields[0].type: Invalid type value 'strng'
    💡 Did you mean 'string'? Valid options: string, integer, decimal, boolean, array, object, uuid

Datenzugriffsschicht generieren

Das Tool generate_data_access_layer generiert typsicheren Python-Code aus Ihrer validierten schema.json-Datei.

Generierter Code:

• Entitätsklassen: Pydantic-Modelle mit Feldvalidierung und Typsicherheit
• Repository-Klassen: CRUD-Operationen (Erstellen, Lesen, Aktualisieren, Löschen) für jede Entität
• Zugriffsmuster: Vollständig implementierte Query- und Scan-Operationen aus Ihrem Schema
• Basis-Repository: Gemeinsam genutzte Funktionalität für alle Repositories
• Nutzungsbeispiele: Beispielcode, der die Verwendung der generierten Klassen demonstriert (optional)
• Konfiguration: ruff.toml für Codequalität und Formatierung

Voraussetzungen für die Code-Generierung:

Der generierte Python-Code benötigt diese Laufzeitabhängigkeiten:

• pydantic>=2.0 – Für Entitätsvalidierung und Typsicherheit
• boto3>=1.38 – Für DynamoDB-Operationen

Installieren Sie sie in Ihrem Projekt:

uv add pydantic boto3
# or
pip install pydantic boto3

Optionale Entwicklungsabhängigkeiten:

Für Linting und Formatierung des generierten Codes:

• ruff==0.15.8 – Python-Linter und -Formatierer (empfohlen)

Generierte Dateistruktur:

generated_dal/
├── entities.py              # Pydantic entity models
├── repositories.py          # Repository classes with CRUD operations
├── base_repository.py       # Base repository functionality
├── transaction_service.py   # Cross-table transaction methods (if schema includes cross_table_access_patterns)
├── access_pattern_mapping.json  # Pattern ID to method mapping
├── usage_examples.py        # Sample usage code (if enabled)
└── ruff.toml               # Linting configuration

Verwendung des generierten Codes:

Der generierte Code bietet typsichere Entitätsklassen und Repository-Methoden für alle Ihre Zugriffsmuster:

from generated_dal.repositories import UserRepository
from generated_dal.entities import User

# Initialize repository
repo = UserRepository(table_name="MyTable")

# Create a new user
user = User(user_id="123", username="username", name="John Doe")
repo.create(user)

# Query by access pattern
users = repo.get_user_by_username(username="username")

# Update user
user.name = "Jane Doe"
repo.update(user)

Für Linting und Formatierung des generierten Codes mit ruff:

ruff check generated_dal/        # Check for issues
ruff check --fix generated_dal/  # Auto-fix issues
ruff format generated_dal/       # Format code