Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bedingungsausdrücke

Wenn Sie Objekte in DynamoDB mithilfe der Operationen,, und DeleteItem DynamoDB mutieren PutItemUpdateItem, können Sie optional einen Bedingungsausdruck angeben, der steuert, ob die Anforderung erfolgreich sein soll oder nicht, basierend auf dem Zustand des Objekts, das sich bereits in DynamoDB befand, bevor der Vorgang ausgeführt wird.

Der AWS AppSync DynamoDB-Resolver ermöglicht die Angabe eines Bedingungsausdrucks in PutItemUpdateItem, und DeleteItem fordert Mapping-Dokumente an sowie eine Strategie, die befolgt werden kann, wenn die Bedingung fehlschlägt und das Objekt nicht aktualisiert wurde.

Beispiel 1

Das folgende PutItem-Zuweisungsdokument enthält keinen Bedingungsausdruck. Dadurch wird ein Element in DynamoDB platziert, auch wenn ein Element mit demselben Schlüssel bereits vorhanden ist, wodurch das vorhandene Element überschrieben wird.

{
   "version" : "2017-02-28",
   "operation" : "PutItem",
   "key" : {
      "id" : { "S" : "1" }
   }
}

Beispiel 2

Das folgende PutItem Mapping-Dokument hat einen Bedingungsausdruck, der nur dann ermöglicht, dass der Vorgang erfolgreich ist, wenn ein Element mit demselben Schlüssel nicht in DynamoDB vorhanden ist.

{
   "version" : "2017-02-28",
   "operation" : "PutItem",
   "key" : {
      "id" : { "S" : "1" }
   },
   "condition" : {
      "expression" : "attribute_not_exists(id)"
   }
}

Wenn die Zustandsprüfung fehlschlägt, gibt der AWS AppSync DynamoDB-Resolver standardmäßig einen Fehler für die Mutation und den aktuellen Wert des Objekts in DynamoDB in einem data Feld im error Abschnitt der GraphQL-Antwort zurück. Der AWS AppSync DynamoDB-Resolver bietet jedoch einige zusätzliche Funktionen, die Entwicklern helfen, einige häufig auftretende Grenzfälle zu bewältigen:

Diese werden im Abschnitt Handling a Condition Check Failure detaillierter beschrieben.

Weitere Informationen zu DynamoDB-Bedingungsausdrücken finden Sie in der ConditionExpressions DynamoDB-Dokumentation.

Angabe einer Bedingung

Die Zuweisungsdokumente der PutItem- UpdateItem- und DeleteItem-Anforderung erlauben das Angeben eines optionalen condition-Abschnitts. Wenn nicht angegeben, wird keine Bedingungsprüfung ausgeführt. Wenn angegeben, muss die Bedingung wahr sein, damit die Operation erfolgreich ausgeführt werden kann.

Ein condition-Abschnitt weist die folgende Struktur auf:

"condition" : {
    "expression" : "someExpression"
    "expressionNames" : {
        "#foo" : "foo"
    },
    "expressionValues" : {
        ":bar" : ... typed value
    },
    "equalsIgnore" : [ "version" ],
    "consistentRead" : true,
    "conditionalCheckFailedHandler" : {
        "strategy" : "Custom",
        "lambdaArn" : "arn:..."
    }
}

Die folgenden Felder geben die Bedingung an:

Die verbleibenden Felder teilen dem AWS AppSync DynamoDB-Resolver mit, wie er mit einem Fehler bei der Zustandsprüfung umgehen soll:

Behandlung eines Fehlers bei der Zustandsprüfung

Wenn eine Zustandsprüfung fehlschlägt, gibt der AWS AppSync DynamoDB-Resolver standardmäßig einen Fehler für die Mutation und den aktuellen Wert des Objekts in DynamoDB in einem data Feld im error Abschnitt der GraphQL-Antwort zurück. Der AWS AppSync DynamoDB-Resolver bietet jedoch einige zusätzliche Funktionen, die Entwicklern helfen, einige häufig auftretende Grenzfälle zu bewältigen:

Das Flussdiagramm für diesen Prozess ist:

Es wird geprüft, ob das gewünschte Ergebnis vorliegt

Wenn die Zustandsprüfung fehlschlägt, führt der AWS AppSync DynamoDB-Resolver eine GetItem DynamoDB-Anforderung aus, um den aktuellen Wert des Elements von DynamoDB abzurufen. Standardmäßig wird ein Strongly Consistent-Lesevorgang verwendet, jedoch kann dies mit dem consistentRead-Feld im condition-Block konfiguriert werden, und mit dem erwarteten Ergebnis verglichen:

Wenn der aktuelle Status des Objekts in DynamoDB vom erwarteten Ergebnis abweicht, folgt der AWS AppSync DynamoDB-Resolver der konfigurierten Strategie, entweder die Mutation zurückzuweisen oder eine Lambda-Funktion aufzurufen, um zu bestimmen, was als Nächstes zu tun ist.

Wir folgen der Strategie „Ablehnen“

Wenn die Reject Strategie befolgt wird, gibt der AWS AppSync DynamoDB-Resolver einen Fehler für die Mutation zurück, und der aktuelle Wert des Objekts in DynamoDB wird auch in einem data Feld im error Abschnitt der GraphQL-Antwort zurückgegeben. Das von DynamoDB zurückgegebene Element durchläuft die Antwortzuordnungsvorlage, um es in ein vom Client erwartetes Format zu übersetzen, und es wird anhand des Auswahlsatzes gefiltert.

Angenommen, Sie haben folgende Mutationsanforderung:

mutation {
    updatePerson(id: 1, name: "Steve", expectedVersion: 1) {
        Name
        theVersion
    }
}

Wenn das von DynamoDB zurückgegebene Element wie folgt aussieht:

{
   "id" : { "S" : "1" },
   "name" : { "S" : "Steve" },
   "version" : { "N" : 8 }
}

Und die Antwortzuweisungsvorlage wie folgt aussieht:

{
   "id" : $util.toJson($context.result.id),
   "Name" : $util.toJson($context.result.name),
   "theVersion" : $util.toJson($context.result.version)
}

Die GraphQL-Antwort sieht wie folgt aus:

{
  "data": null,
  "errors": [
    {
      "message": "The conditional request failed (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: ConditionalCheckFailedException; Request ID: ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ)"
      "errorType": "DynamoDB:ConditionalCheckFailedException",
      "data": {
        "Name": "Steve",
        "theVersion": 8
      },
      ...
    }
  ]
}

Beachten Sie auch, dass, wenn bei einer erfolgreichen Mutation alle Felder im zurückgegebenen Objekt von anderen Resolvern ausgefüllt werden, diese nicht auf den Resolver angewendet werden, wenn das Objekt im error-Abschnitt zurückgegeben wird.

Folgen Sie der „benutzerdefinierten“ Strategie

Wenn die Custom Strategie befolgt wird, ruft der AWS AppSync DynamoDB-Resolver eine Lambda-Funktion auf, um zu entscheiden, was als Nächstes zu tun ist. Die Lambda-Funktion wählt eine der folgenden Optionen aus:

Die Lambda-Aufrufanforderung

Der AWS AppSync DynamoDB-Resolver ruft die in der angegebene Lambda-Funktion auf. lambdaArn Er verwendet die gleiche service-role-arn-Konfiguration für die Datenquelle. Die Nutzlast des Aufrufs hat die folgende Struktur:

{
    "arguments": { ... },
    "requestMapping": {... },
    "currentValue": { ... },
    "resolver": { ... },
    "identity": { ... }
}

Die Felder sind wie folgt definiert:

Ein vollständiges Beispiel für die Nutzlast:

{
    "arguments": {
        "id": "1",
        "name": "Steve",
        "expectedVersion": 1
    },
    "requestMapping": {
        "version" : "2017-02-28",
        "operation" : "PutItem",
        "key" : {
           "id" : { "S" : "1" }
        },
        "attributeValues" : {
           "name" : { "S" : "Steve" },
           "version" : { "N" : 2 }
        },
        "condition" : {
           "expression" : "version = :expectedVersion",
           "expressionValues" : {
               ":expectedVersion" : { "N" : 1 }
           },
           "equalsIgnore": [ "version" ]
        }
    },
    "currentValue": {
        "id" : { "S" : "1" },
        "name" : { "S" : "Steve" },
        "version" : { "N" : 8 }
    },
    "resolver": {
        "tableName": "People",
        "awsRegion": "us-west-2",
        "parentType": "Mutation",
        "field": "updatePerson",
        "outputType": "Person"
    },
    "identity": {
        "accountId": "123456789012",
        "sourceIp": "x.x.x.x",
        "user": "AIDAAAAAAAAAAAAAAAAAA",
        "userArn": "arn:aws:iam::123456789012:user/appsync"
    }
}

Die Lambda-Aufrufantwort

Die Lambda-Funktion kann die Nutzlast des Aufrufs untersuchen und jede Geschäftslogik anwenden, um zu entscheiden, wie der AWS AppSync DynamoDB-Resolver mit dem Fehler umgehen soll. Es gibt drei Optionen für den Umgang mit dem Bedingungsprüfungsfehler:

Hier sehen Sie ein Beispiel für eine Lambda-Funktion zum Umgang mit einer fehlgeschlagenen PutItem-Anforderung. Die Geschäftslogik prüft, wer den Aufruf ausgeführt hat. Wenn es von erstellt wurdejeffTheAdmin, wiederholt es die Anfrage und aktualisiert das version und expectedVersion aus dem Element, das sich derzeit in DynamoDB befindet. Andernfalls wird die Mutation ablehnt.

exports.handler = (event, context, callback) => {
    console.log("Event: "+ JSON.stringify(event));

    // Business logic goes here.

    var response;
    if ( event.identity.user == "jeffTheAdmin" ) {
        response = {
            "action" : "retry",
            "retryMapping" : {
                "attributeValues" : event.requestMapping.attributeValues,
                "condition" : {
                    "expression" : event.requestMapping.condition.expression,
                    "expressionValues" : event.requestMapping.condition.expressionValues
                }
            }
        }
        response.retryMapping.attributeValues.version = { "N" : event.currentValue.version.N + 1 }
        response.retryMapping.condition.expressionValues[':expectedVersion'] = event.currentValue.version

    } else {
        response = { "action" : "reject" }
    }

    console.log("Response: "+ JSON.stringify(response))
    callback(null, response)
};