Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Espressioni di condizione

Quando modifichi oggetti in DynamoDB utilizzando le operazioniPutItem,, e DeleteItem DynamoDBUpdateItem, puoi facoltativamente specificare un'espressione di condizione che controlli se la richiesta deve avere successo o meno, in base allo stato dell'oggetto già in DynamoDB prima dell'esecuzione dell'operazione.

Il resolver AWS AppSync DynamoDB consente di specificare un'espressione di condizione e DeleteItem richiedere documenti di mappatura e anche una strategia da seguire se la condizione fallisce e l'oggetto non è stato aggiornato. PutItem UpdateItem

Esempio 1

Il seguente documento di mappatura PutItem non contiene un'espressione di condizione. Di conseguenza, inserisce un elemento in DynamoDB anche se esiste già un elemento con la stessa chiave, sovrascrivendo così l'elemento esistente.

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

Esempio 2

Il seguente documento di PutItem mappatura ha un'espressione di condizione che consente all'operazione di avere successo solo se un elemento con la stessa chiave non esiste in DynamoDB.

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

Per impostazione predefinita, se il controllo delle condizioni fallisce, il resolver AWS AppSync DynamoDB restituisce un errore per la mutazione. Tuttavia, il resolver AWS AppSync DynamoDB offre alcune funzionalità aggiuntive per aiutare gli sviluppatori a gestire alcuni casi limite comuni:

Queste vengono descritte in dettaglio nella sezione Gestione di un errore nel controllo della condizione.

Per ulteriori informazioni sulle espressioni delle condizioni di DynamoDB, consulta la documentazione di DynamoDB. ConditionExpressions

Specificare una condizione

I documenti di mappatura della richiesta PutItem, UpdateItem e DeleteItem consentono tutti di specificare una sezione facoltativa condition. Se omessa, non vengono eseguiti controlli di condizione. Se specificata, la condizione deve essere soddisfatta perché l'operazione abbia esito positivo.

Una sezione condition ha la seguente struttura:

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

I seguenti campi specificano la condizione:

I campi rimanenti indicano al resolver AWS AppSync DynamoDB come gestire un errore di verifica delle condizioni:

Gestione di un errore di verifica delle condizioni

Per impostazione predefinita, quando un controllo delle condizioni fallisce, il resolver AWS AppSync DynamoDB restituisce un errore per la mutazione e il valore corrente dell'oggetto in DynamoDB. Tuttavia, il resolver AWS AppSync DynamoDB offre alcune funzionalità aggiuntive per aiutare gli sviluppatori a gestire alcuni casi limite comuni:

Il diagramma di questo processo è il seguente:

Verifica del risultato desiderato

Quando il controllo delle condizioni ha esito negativo, il resolver AWS AppSync DynamoDB esegue una richiesta GetItem DynamoDB per ottenere il valore corrente dell'elemento da DynamoDB. Per impostazione predefinita, si utilizza una lettura fortemente consistente, ma è possibile intervenire sulla configurazione utilizzando il campo consistentRead del blocco condition e confrontandolo con il risultato previsto:

Se lo stato corrente dell'oggetto in DynamoDB è diverso dal risultato previsto, il resolver AWS AppSync DynamoDB segue la strategia configurata, per rifiutare la mutazione o richiamare una funzione Lambda per determinare cosa fare dopo.

Seguendo la strategia di «rifiuto»

Quando si segue la Reject strategia, il resolver AWS AppSync DynamoDB restituisce un errore per la mutazione.

Ad esempio, partendo dalla richiesta di mutazione seguente:

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

Se l'elemento restituito da DynamoDB è simile al seguente:

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

E il modello di mappatura della risposta fosse simile al seguente:

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

La risposta GraphQL ha il seguente aspetto:

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

Inoltre, se i campi dell'oggetto restituito sono compilati da altri resolver in caso di successo della mutazione, tali campi non saranno risolti quando l'oggetto viene restituito nella sezione error.

Seguendo la strategia «personalizzata»

Quando si segue la Custom strategia, il resolver AWS AppSync DynamoDB richiama una funzione Lambda per decidere cosa fare dopo. La funzione Lambda sceglie una delle seguenti opzioni:

La richiesta di invocazione Lambda

Il resolver AWS AppSync DynamoDB richiama la funzione Lambda specificata in. lambdaArn Utilizza lo stesso service-role-arn configurato per l'origine dati. Il payload dell'invocazione ha la seguente struttura:

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

I campi sono definiti come segue:

Un esempio completo di payload:

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

La risposta all'invocazione Lambda

La funzione Lambda può ispezionare il payload di chiamata e applicare qualsiasi logica aziendale per decidere come il resolver DynamoDB deve gestire l' AWS AppSync errore. Sono disponibili tre opzioni per la gestione dell'errore nel controllo della condizione:

Ecco un esempio di funzione Lambda per far fronte a una richiesta PutItem non riuscita. La logica di business osserva l'autore della chiamata. Se è stato effettuato dajeffTheAdmin, riprova la richiesta, aggiornando il valore version e expectedVersion dall'elemento attualmente presente in DynamoDB. Altrimenti rifiuta la mutazione.

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