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 ändern PutItemUpdateItem, können Sie optional einen Bedingungsausdruck angeben, der steuert, ob die Anforderung erfolgreich sein soll oder nicht, basierend auf dem Status des Objekts, das sich bereits in DynamoDB befindet, bevor der Vorgang ausgeführt wird.

Der AWS AppSync DynamoDB-Resolver ermöglicht die Angabe eines Bedingungsausdrucks in und die DeleteItem Anforderung von Zuordnungsdokumenten sowie eine Strategie PutItemUpdateItem, die befolgt werden muss, wenn die Bedingung fehlschlägt und das Objekt nicht aktualisiert wurde.

Beispiel 1

Das folgende PutItem-Zuweisungsdokument enthält keinen Bedingungsausdruck. Daher fügt er ein Element in DynamoDB ein, auch wenn bereits ein Element mit demselben Schlüssel existiert, wodurch das vorhandene Element überschrieben wird.

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

Beispiel 2

Das folgende PutItem Zuordnungsdokument enthält einen Bedingungsausdruck, der es ermöglicht, dass der Vorgang nur dann erfolgreich ist, wenn ein Element mit demselben Schlüssel in DynamoDB nicht vorhanden ist.

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

Wenn die Bedingungsprüfung fehlschlägt, gibt der AWS AppSync DynamoDB-Resolver standardmäßig einen Fehler für die Mutation zurück. Der AWS AppSync DynamoDB-Resolver bietet jedoch einige zusätzliche Funktionen, um Entwicklern bei der Bewältigung einiger häufiger Randfälle zu helfen:

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

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

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 ein Fehler bei der Zustandsprüfung zu behandeln ist:

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 zurück. Der AWS AppSync DynamoDB-Resolver bietet jedoch einige zusätzliche Funktionen, um Entwicklern bei der Bewältigung einiger häufiger Randfälle zu helfen:

Das Flussdiagramm für diesen Prozess ist:

Auf der Suche nach dem gewünschten Ergebnis

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.

Folgt der Strategie „Ablehnen“

Wenn Sie der Reject Strategie folgen, gibt der AWS AppSync DynamoDB-Resolver einen Fehler für die Mutation zurück.

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",
      ...
    }
  ]
}

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.

Wir folgen der „benutzerdefinierten“ Strategie

Wenn Sie der Custom Strategie folgen, 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 überprüfen und jede Geschäftslogik anwenden, um zu entscheiden, wie der AWS AppSync DynamoDB-Resolver den Fehler behandeln 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 er von gestellt wurdejeffTheAdmin, wiederholt er die Anfrage und aktualisiert dabei 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)
};