DynamoDB Query Builder
Stelle die komplette Query- oder Scan-Anfrage zusammen — Tabelle, Index, Key Condition, Filter, Projection, Limit, Sortierreihenfolge, konsistente Lesevorgänge und Pagination — und kopiere ein lauffähiges Programm für AWS SDK v3, DocumentClient, CLI, boto3, Java, Go, .NET, Rust, Kotlin, PHP, Ruby oder DynamoDB-Toolbox, oder das PartiQL-Statement.
dynamodb-expression-builder ist die Open-Source-Bibliothek (MIT) hinter diesem Tool.
Vom Zugriffsmuster zum lauffähigen Request
Die Expression ist selten die ganze Arbeit. Eine Produktions-Query entscheidet auch, welcher Index gelesen wird, wie viele Items pro Request ausgewertet werden, in welche Richtung der Sort Key läuft, ob der Lesevorgang stark konsistent sein muss und was passiert, wenn die Antwort mit einem LastEvaluatedKey zurückkommt. Diese Request-Parameter leben außerhalb des Expression-Strings — und genau dort gehen kopierte Snippets meist schief.
Dieser Builder behandelt den Request als Arbeitseinheit. Du setzt Key-Bedingung, Filter und Projektion auf demselben typisierten, Reserved-Word-sicheren Modell zusammen, das unser Expression Builder nutzt, und stellst daneben die Request-Optionen ein. Die Ausgabe ist kein Fragment, sondern ein lauffähiges Programm — Imports, Client-Setup, der Aufruf selbst und, wenn du „Alle Seiten laden“ aktivierst, die ExclusiveStartKey-Schleife, die jede Ergebnisseite abholt.
Der generierte Code bleibt bei jedem Ziel ehrlich. Die AWS CLI paginiert von selbst, daher wird ihr Limit zu --page-size und ein Einzel-Request bekommt --no-paginate; PartiQL lehnt die Parameter ab, die zur ExecuteStatement-API statt zum Statement gehören; und eine absteigende Query wird zu ORDER BY auf deinem Sort Key, wo das ausdrückbar ist.
Brauchst du nur die Expression selbst — eine Condition-, Filter- oder Update-Expression mit ihren Platzhalter-Maps, für eine der sechs Operationen? Der DynamoDB Expression Builder ist genau dafür gebaut. Entscheidest du dich erst noch zwischen den beiden Leseoperationen? Query vs. Scan erklärt, wann welche die richtige Wahl ist.
Häufig gestellte Fragen
Worin unterscheidet sich das vom DynamoDB Expression Builder?
Die beiden teilen sich das Problem bewusst auf. Der Expression Builder dreht sich um Expression-Syntax — Key-Bedingungen, Filter, Update- und Condition-Expressions mit ihren ExpressionAttributeNames/-Values-Maps — über alle sechs Operationen hinweg und gibt den nackten Befehl aus. Der Query Builder dreht sich um den kompletten Query- oder Scan-Request: Tabelle und Index, Key-Bedingung, Filter, Projektion, plus die Request-Parameter, die das Expression-Tool nicht anbietet (Limit, Sortierreihenfolge, ConsistentRead, ExclusiveStartKey) — und er gibt ein lauffähiges Programm mit Client-Setup und optionaler Paginierungsschleife aus.
Was begrenzt Limit bei einer Query oder einem Scan wirklich?
Limit begrenzt, wie viele Items DynamoDB pro Request auswertet — nicht, wie viele passende Items du zurückbekommst. Filter laufen nach dem Lesen, daher kann eine Query mit Limit 25 und einer FilterExpression weniger als 25 Items liefern — oder gar keine — und verbraucht trotzdem die Lesekapazität für alles, was ausgewertet wurde; die Paginierung läuft ab dem LastEvaluatedKey weiter. In der AWS CLI, die automatisch paginiert, setzt man denselben Parameter mit --page-size.
Wie funktioniert die DynamoDB-Paginierung (LastEvaluatedKey)?
Eine Query- oder Scan-Antwort mit weiteren Daten enthält einen LastEvaluatedKey — den Primärschlüssel des zuletzt gelesenen Items. Du gibst ihn bei der nächsten Anfrage als ExclusiveStartKey zurück und wiederholst das, bis eine Antwort ohne ihn eintrifft. Aktiviere „Alle Seiten abrufen“, und die erzeugten Programme für SDK v3, boto3, Java und .NET enthalten genau diese Schleife; Go, Rust, Kotlin, PHP, Ruby und der DocumentClient nutzen den nativen Paginator ihres SDKs; die AWS CLI folgt den Seiten von selbst, sofern du nicht --no-paginate angibst.
Wann kann ich einen stark konsistenten Lesevorgang verwenden?
ConsistentRead funktioniert auf Basistabellen und Local Secondary Indexes, aber nicht auf Global Secondary Indexes — eine Query gegen einen GSI mit gesetztem ConsistentRead wird abgelehnt. Ein stark konsistenter Lesevorgang verbraucht außerdem doppelt so viel Lesekapazität wie ein eventual-konsistenter. Es ist ein API-Parameter und kein Teil des PartiQL-Statement-Texts — deshalb lehnt der PartiQL-Tab ihn ehrlich ab.
Wird irgendetwas, das ich hier eingebe, irgendwohin hochgeladen?
Nein. Das ist eine statische Seite: Der Request wird komplett in deinem Browser zusammengesetzt und der Code dort generiert — Tabellennamen, Key-Werte und Filter erreichen nie einen Server. „Link kopieren“ packt den ganzen Request in die URL — diesen Link zu teilen ist der einzige Weg, auf dem etwas von deinen Eingaben die Seite verlässt, und das liegt bei dir.