Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Expressions de condition

Lorsque vous mutez des objets dans DynamoDB à l'aide des opérationsPutItem,UpdateItem, et DeleteItem DynamoDB, vous pouvez éventuellement spécifier une expression de condition qui détermine si la demande doit aboutir ou non, en fonction de l'état de l'objet déjà présent dans DynamoDB avant l'exécution de l'opération.

Le résolveur AWS AppSync DynamoDB permet de spécifier une expression de condition PutItem dans DeleteItem et de demander des documents de mappageUpdateItem, ainsi qu'une stratégie à suivre si la condition échoue et que l'objet n'a pas été mis à jour.

Exemple 1

Le document de mappage PutItem suivant ne dispose pas d'une expression de condition. Par conséquent, il place un élément dans DynamoDB même s'il existe déjà un élément portant la même clé, remplaçant ainsi l'élément existant.

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

Exemple 2

Le document de PutItem mappage suivant contient une expression de condition qui permet à l'opération de réussir uniquement si un élément portant la même clé n'existe pas dans DynamoDB.

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

Par défaut, si le contrôle de condition échoue, le résolveur AWS AppSync DynamoDB renvoie une erreur concernant la mutation et la valeur actuelle de l'objet dans DynamoDB dans un data champ de la section de la réponse GraphQL. error Cependant, le résolveur AWS AppSync DynamoDB propose des fonctionnalités supplémentaires pour aider les développeurs à gérer certains cas extrêmes courants :

Cette opération est décrite plus en détail dans la section Gestion d'un échec de contrôle de condition.

Pour plus d'informations sur les expressions de conditions DynamoDB, consultez la documentation DynamoDB. ConditionExpressions

Spécifier une condition

Les documents de mappage des demandes PutItem, UpdateItem et DeleteItem permettent tous la spécification d'une section de condition facultative. Si cette section est omise, aucune vérification de condition n'est effectuée. Si elle est spécifiée, la condition doit être true pour que l'opération réussisse.

Une section condition a la structure suivante :

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

Les champs suivants spécifient la condition :

Les champs restants indiquent au résolveur AWS AppSync DynamoDB comment gérer un échec de vérification de condition :

Gestion d'un échec de vérification d'état

Par défaut, lorsqu'une vérification de condition échoue, le résolveur AWS AppSync DynamoDB renvoie une erreur concernant la mutation et la valeur actuelle de l'objet dans DynamoDB dans un data champ de la section de la réponse GraphQL. error Cependant, le résolveur AWS AppSync DynamoDB propose des fonctionnalités supplémentaires pour aider les développeurs à gérer certains cas extrêmes courants :

Le diagramme de ce processus est le suivant :

Vérification du résultat souhaité

Lorsque le contrôle de condition échoue, le résolveur AWS AppSync DynamoDB exécute GetItem une requête DynamoDB pour obtenir la valeur actuelle de l'élément auprès de DynamoDB. Par défaut, il utilise une lecture à cohérence forte, mais cela peut être configuré à l'aide du champ consistentRead dans le bloc condition et comparé aux résultats prévus :

Si l'état actuel de l'objet dans DynamoDB est différent du résultat attendu, le résolveur AWS AppSync DynamoDB suit la stratégie configurée, soit pour rejeter la mutation, soit pour invoquer une fonction Lambda pour déterminer la marche à suivre.

Suivre la stratégie du « rejet »

Lorsque vous suivez Reject cette stratégie, le résolveur AWS AppSync DynamoDB renvoie une erreur pour la mutation, et la valeur actuelle de l'objet dans DynamoDB est également renvoyée dans un data champ de la section de la réponse GraphQL. error L'élément renvoyé par DynamoDB est soumis au modèle de mappage des réponses pour le traduire dans le format attendu par le client, puis il est filtré par le jeu de sélection.

Par exemple, si nous avons la demande de mutation suivante :

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

Si l'élément renvoyé par DynamoDB ressemble à ce qui suit :

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

Et si le modèle de mappage des réponses ressemble à ce qui suit :

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

La réponse GraphQL se présente comme suit :

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

Notez également que si des champs de l'objet renvoyé sont remplis par d'autres résolveurs et que la mutation a réussi, ils ne seront pas résolus lorsque l'objet sera renvoyé dans la section error.

Suivre la stratégie « personnalisée »

Lorsqu'il suit la Custom stratégie, le résolveur AWS AppSync DynamoDB invoque une fonction Lambda pour décider de la marche à suivre. La fonction Lambda choisit l'une des options suivantes :

Requête d'appel Lambda

Le résolveur AWS AppSync DynamoDB invoque la fonction Lambda spécifiée dans le. lambdaArn Il utilise le même service-role-arn que celui configuré sur la source de données. La charge utile de l'appel a la structure suivante :

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

Les champs sont définis comme suit :

Exemple complet de la charge utile :

{
    "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"
    }
}

Réponse à l'appel de Lambda

La fonction Lambda peut inspecter la charge utile d'appel et appliquer n'importe quelle logique métier pour décider de la manière dont le résolveur DynamoDB doit gérer AWS AppSync la panne. Il existe trois options pour gérer l'échec de vérification de la condition :

Voici un exemple de fonction Lambda pour traiter une demande PutItem qui a échoué. La logique métier s'adresse à celui qui effectue l'appel. S'il a été créé parjeffTheAdmin, il réessaie la demande en mettant à jour le version et à expectedVersion partir de l'élément actuellement présent dans DynamoDB. Dans le cas contraire, il rejette la mutation.

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)
};