Kostenloses Tool

DynamoDB Expression Builder

Wähle eine Operation, baue die Anfrage visuell auf und kopiere einen korrekten, gegen reservierte Wörter abgesicherten Ausdruck — mit seinen ExpressionAttributeNames und Values — als AWS SDK v3, CLI, boto3 oder PartiQL.

Erstelle deine Anfrage
Generierter Code
new QueryCommand({
  "TableName": "MyTable",
  "KeyConditionExpression": "#hashKey = :hashKeyValue AND begins_with(#rangeKey, :rangeKeyValue)",
  "ExpressionAttributeNames": {
    "#hashKey": "pk",
    "#rangeKey": "sk"
  },
  "ExpressionAttributeValues": {
    ":hashKeyValue": {
      "S": "USER#123"
    },
    ":rangeKeyValue": {
      "S": "ORDER#"
    }
  }
})

Warum das händische Schreiben von DynamoDB-Ausdrücken fehleranfällig ist

Eine DynamoDB-Anfrage scheitert selten am offensichtlichen Teil. Sie scheitert, weil status ein reserviertes Wort ist und einen #-Alias braucht, weil eine numerische id als String gesendet wurde und zu nichts passte, oder weil eine FilterExpression und eine ConditionExpression denselben :v0-Platzhalter wiederverwendet haben. Jeder ist ein kleiner Fehler, der eine Anfrage erzeugt, die läuft, aber die falschen Zeilen zurückgibt — die schlimmste Art zum Debuggen.

Dieser Builder setzt die gesamte Anfrage aus einem typisierten Modell zusammen. Jeder Attributname wird aliasiert, jeder Wert trägt einen expliziten DynamoDB-Typ, und Key-, Filter-, Bedingungs- und Update-Platzhalter leben in separaten Namespaces, sodass Kollisionen konstruktionsbedingt unmöglich sind. Die Ausgabe wird aus den Typ-Tags aufgebaut, nicht aus deinem Text erraten — eine Zahl bleibt eine Zahl, ein base64-String bleibt binär.

Update-Expressions und bedingte Schreibvorgänge werden genauso behandelt: atomare Counter, if_not_exists, list_append, REMOVE auf einem List-Index, ADD/DELETE auf Sets und Bedingungen für optimistisches Locking fügen sich alle zu einer korrekten UpdateExpression und ConditionExpression zusammen. Der PartiQL-Tab ist ehrlich — wenn ein Primitiv keine PartiQL-Form hat, sagt er dir welches, statt ein Statement auszugeben, das sich stillschweigend falsch verhält.

Erst zwischen Query und Scan entscheiden? Query vs. Scan erklärt den Unterschied, und PartiQL-Beispiele behandelt die SQL-ähnliche Syntax im Detail.

Häufig gestellte Fragen

Was ist ein ExpressionAttributeName, und warum die Präfixe # und :?

DynamoDB-Ausdrücke können einen Attributnamen, der ein reserviertes Wort ist (wie name, status oder size), nicht direkt referenzieren, und ein Wert-Platzhalter hält die eigentlichen Daten aus dem Ausdrucks-String heraus. Daher wird jeder Attributname mit einem #-Platzhalter in ExpressionAttributeNames und jeder Wert mit einem :-Platzhalter in ExpressionAttributeValues aliasiert. Dieser Builder erzeugt diese Maps für dich, sodass ein reserviertes Wort deine Anfrage nie kaputtmacht.

Warum muss ich für jeden Wert einen Typ (S, N, B…) auswählen?

DynamoDB ist auf Attributebene typisiert: Die Zahl 5 ist { "N": "5" } und der String "5" ist { "S": "5" } — unterschiedliche Werte, die zu unterschiedlichen Items passen. Eine Texteingabe kann sie nicht unterscheiden, daher bittet dich der Builder, jeden Wert zu kennzeichnen. Die ausgegebene SDK-, CLI-, boto3- und PartiQL-Ausgabe wird aus dieser Kennzeichnung aufgebaut, nie aus dem Text erraten, sodass eine numerische id eine Zahl bleibt und ein base64-Blob binär bleibt.

Kann er Update-Expressions und bedingte Schreibvorgänge erstellen?

Ja. Update deckt SET (einschließlich if_not_exists, atomare +/- Counter und list_append), REMOVE (einschließlich eines List-Index wie #a[2]), ADD (Zahl oder Set) und DELETE (Set-Mitglieder) ab — kombiniert in einer UpdateExpression. Bedingte Schreibvorgänge fügen Update, Put oder Delete eine ConditionExpression für optimistisches Locking hinzu (attribute_not_exists, eine Versionsprüfung und so weiter). Key-Bedingungen und Wert-Bedingungen verwenden separate Platzhalter-Namespaces, sodass sie nie kollidieren.

Warum ist PartiQL manchmal „nicht ausdrückbar“?

PartiQL deckt die meisten Lese- und Schreibvorgänge ab, aber einige DynamoDB-Primitive haben keine PartiQL-Form: ein bedingtes INSERT, die Set-typisierten Update-Aktionen ADD/DELETE sowie Funktionen wie size(), list_append und if_not_exists. Wenn deine Anfrage eine davon verwendet, sagt dir der PartiQL-Tab genau, welches Feature nicht ausdrückbar ist, statt ein Statement auszugeben, das stillschweigend das Falsche täte — nutze für diese die SDK-, CLI- oder boto3-Ausgabe.

Verlassen meine Daten den Browser?

Nein. Der Builder läuft vollständig clientseitig — er erzeugt die Ausdrücke und Code-Snippets in deinem Browser, und nichts, was du eingibst, wird an einen Server gesendet. Die „Link kopieren“-Funktion der URL serialisiert deine Anfrage in den Link selbst, sodass du ihn teilen oder als Lesezeichen speichern kannst, aber das bleibt in deinen Händen.

Mit DynamoDB ohne die Console arbeiten

DynoTable ist ein schneller Desktop-Client für DynamoDB — durchsuche Tabellen, führe SQL-artige Queries aus und bearbeite Items lokal.