Espressioni di condizione - AWS AppSync
Esempio 1Esempio 2Specificare una condizioneGestione di un errore di controllo delle condizioni

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 modificate gli oggetti in DynamoDB utilizzando le operazioniPutItem, e DeleteItem DynamoDBUpdateItem, potete 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 AWS AppSync resolver DynamoDB consente di specificare PutItem un'espressione di condizione DeleteItem e richiedere documenti di mappaturaUpdateItem, nonché una strategia da seguire se la condizione fallisce e l'oggetto non è stato aggiornato.

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 contiene un'espressione di condizione che consente il successo dell'operazione 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 AWS AppSync resolver DynamoDB restituisce un errore per la mutazione e il valore corrente dell'oggetto in DynamoDB in un campo nella sezione della risposta GraphQL. data error Tuttavia, il AWS AppSync resolver DynamoDB offre alcune funzionalità aggiuntive per aiutare gli sviluppatori a gestire alcuni casi limite comuni:

  • Se AWS AppSync il resolver DynamoDB è in grado di determinare che il valore corrente in DynamoDB corrisponde al risultato desiderato, considera l'operazione come se fosse riuscita comunque.

  • Invece di restituire un errore, puoi configurare il resolver per richiamare una funzione Lambda personalizzata per decidere come il resolver DynamoDB deve gestire AWS AppSync l'errore.

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:

expression

L'espressione di aggiornamento in sé. Per ulteriori informazioni su come scrivere espressioni di condizione, consulta la documentazione di ConditionExpressions DynamoDB. Questo campo deve essere specificato.

expressionNames

Le sostituzioni per i segnaposto dell'attributo di espressione name, sotto forma di coppie chiave-valore. La chiave corrisponde a un segnaposto per il nome utilizzato nell'espressione e il valore deve essere una stringa corrispondente al nome dell'attributo dell'elemento in DynamoDB. Questo è un campo facoltativo in cui vanno riportate solo le sostituzioni per i segnaposto dell'attributo di espressione name utilizzate inexpression.

expressionValues

Le sostituzioni per i segnaposto del valore dell'attributo di espressione, sotto forma di coppie chiave-valore. La chiave corrisponde a un segnaposto per un valore utilizzato nell'espressione, mentre il valore deve essere un valore tipizzato. Per ulteriori informazioni su come specificare un "valore tipizzato", consulta Sistema di tipi (mappatura della richiesta). Questo elemento deve essere specificato. Questo è un campo facoltativo in cui vanno riportate solo le sostituzioni per i segnaposto dell'attributo di espressione value utilizzate nell'espressione.

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

equalsIgnore

Quando un controllo delle condizioni fallisce durante l'utilizzo dell'PutItemoperazione, il resolver AWS AppSync DynamoDB confronta l'elemento attualmente in DynamoDB con l'elemento che ha cercato di scrivere. Se sono uguali, tratta l'operazione come se avesse avuto comunque esito positivo. È possibile utilizzare il equalsIgnore campo per specificare un elenco di attributi da ignorare quando si esegue il AWS AppSync confronto. Ad esempio, se l'unica differenza era un version attributo, considera l'operazione come se fosse riuscita. Questo campo è facoltativo.

consistentRead

Quando un controllo delle condizioni fallisce, AWS AppSync ottiene il valore corrente dell'elemento da DynamoDB utilizzando una lettura fortemente coerente. È possibile utilizzare questo campo per indicare al resolver AWS AppSync DynamoDB di utilizzare invece una lettura alla fine coerente. Si tratta di un campo facoltativo, impostato di default su true.

conditionalCheckFailedHandler

Questa sezione consente di specificare in che modo il resolver AWS AppSync DynamoDB tratta un errore di controllo delle condizioni dopo aver confrontato il valore corrente in DynamoDB con il risultato previsto. Questa sezione è facoltativa. Se omesso, la strategia predefinita è Reject.

strategy

La strategia adottata dal AWS AppSync resolver DynamoDB dopo aver confrontato il valore corrente in DynamoDB con il risultato previsto. Questo campo è obbligatorio e ha i seguenti possibili valori:

Reject

La mutazione ha esito negativo e viene visualizzato un errore per la mutazione e il valore corrente dell'oggetto in DynamoDB in un data campo nella sezione error della risposta GraphQL.

Custom

Il AWS AppSync resolver DynamoDB richiama una funzione Lambda personalizzata per decidere come gestire l'errore del controllo delle condizioni. Quando strategy è impostato suCustom, il lambdaArn campo deve contenere la ARN funzione Lambda da richiamare.

lambdaArn

La ARN funzione Lambda da richiamare che determina in che modo il resolver DynamoDB deve gestire l' AWS AppSync errore del controllo delle condizioni. Questo campo deve essere specificato solo se strategy è impostato su Custom. Per ulteriori informazioni su come utilizzare questa funzionalità, consulta Gestione di un errore nel controllo della condizione.

Gestione di un errore di controllo delle condizioni

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

  • Se AWS AppSync il resolver DynamoDB è in grado di determinare che il valore corrente in DynamoDB corrisponde al risultato desiderato, considera l'operazione come se fosse riuscita comunque.

  • Invece di restituire un errore, puoi configurare il resolver per richiamare una funzione Lambda personalizzata per decidere come il resolver DynamoDB deve gestire AWS AppSync l'errore.

Il diagramma di questo processo è il seguente:

Verifica del risultato desiderato

Quando il controllo delle condizioni fallisce, il resolver AWS AppSync DynamoDB esegue GetItem una richiesta 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:

  • Per l'PutItemoperazione, il AWS AppSync resolver DynamoDB confronta il valore corrente con quello che ha tentato di scrivere, escludendo dal confronto tutti gli attributi elencati. equalsIgnore Se gli elementi sono uguali, considera l'operazione come riuscita e restituisce l'elemento recuperato da DynamoDB. In caso contrario, viene seguita la strategia configurata.

    Ad esempio, se il documento di mappatura della richiesta PutItem fosse simile al seguente:

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

    E la voce attualmente inclusa in DynamoDB fosse simile alla seguente:

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

    Il AWS AppSync resolver DynamoDB confronta l'elemento che ha cercato di scrivere con il valore corrente, verifica che l'unica differenza è version il campo, ma poiché è configurato per ignorare il campo, considera version l'operazione come riuscita e restituisce l'elemento recuperato da DynamoDB.

  • Per l'DeleteItemoperazione, il resolver AWS AppSync DynamoDB verifica che un elemento sia stato restituito da DynamoDB. Se nessuna voce è stata restituita, considera l'operazione riuscita. In caso contrario, viene seguita la strategia configurata.

  • Per l'UpdateItemoperazione, il AWS AppSync resolver DynamoDB non dispone di informazioni sufficienti per determinare se l'elemento attualmente in DynamoDB corrisponde al risultato previsto e pertanto segue la strategia configurata.

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

Seguendo la strategia di «rifiuto»

Quando si segue la Reject strategia, il AWS AppSync resolver DynamoDB restituisce un errore per la mutazione e il valore corrente dell'oggetto in DynamoDB viene restituito anche in un campo nella sezione della risposta GraphQL. data error L'elemento restituito da DynamoDB viene inserito nel modello di mappatura delle risposte per tradurlo nel formato previsto dal client e viene filtrato in base al set di selezione.

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",
      "data": {
        "Name": "Steve",
        "theVersion": 8
      },
      ...
    }
  ]
}

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 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:

  • Rifiuto della mutazione (reject). Ciò indica al AWS AppSync resolver DynamoDB di comportarsi come se lo Reject fosse la strategia configurata, restituendo un errore per la mutazione e il valore corrente dell'oggetto in DynamoDB come descritto nella sezione precedente.

  • Rifiuto della mutazione (discard). Ciò indica al resolver AWS AppSync DynamoDB di ignorare silenziosamente l'errore del controllo delle condizioni e restituisce il valore in DynamoDB.

  • Rifiuto della mutazione (retry). Questo indica al resolver AWS AppSync DynamoDB di riprovare la mutazione con un nuovo documento di mappatura delle richieste.

La richiesta di invocazione Lambda

Il AWS AppSync resolver 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:

arguments

Gli argomenti della mutazione GraphQL. Sono uguali agli argomenti disponibili per il documento di mappatura della richiesta in $context.arguments.

requestMapping

Il documento di mappatura della richiesta per questa operazione.

currentValue

Il valore corrente dell'oggetto in DynamoDB.

resolver

Informazioni sul resolver. AWS AppSync

identity

Informazioni sul chiamante. Sono uguali alle informazioni sull'identità disponibili per il documento di mappatura della richiesta in $context.identity.

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'errore AWS AppSync . Sono disponibili tre opzioni per la gestione dell'errore nel controllo della condizione:

  • Rifiuto della mutazione (reject). Il payload di risposta per questa opzione deve avere questa struttura:

    {
    "action": "reject"
}

    Ciò indica al AWS AppSync resolver DynamoDB di comportarsi come se la strategia configurata lo Reject fosse, restituendo un errore per la mutazione e il valore corrente dell'oggetto in DynamoDB, come descritto nella sezione precedente.

  • Rifiuto della mutazione (discard). Il payload di risposta per questa opzione deve avere questa struttura:

    {
    "action": "discard"
}

    Ciò indica al resolver AWS AppSync DynamoDB di ignorare silenziosamente l'errore del controllo delle condizioni e restituisce il valore in DynamoDB.

  • Rifiuto della mutazione (retry). Il payload di risposta per questa opzione deve avere questa struttura:

    {
    "action": "retry",
    "retryMapping": { ... }
}

    Questo indica al resolver AWS AppSync DynamoDB di riprovare la mutazione con un nuovo documento di mappatura delle richieste. La struttura della retryMapping sezione dipende dall'operazione DynamoDB ed è un sottoinsieme del documento completo di mappatura delle richieste per quell'operazione.

    Per PutItem, la sezione retryMapping ha la seguente struttura. Per una descrizione del campo, vedere. attributeValues PutItem

    {
    "attributeValues": { ... },
    "condition": {
        "equalsIgnore" = [ ... ],
        "consistentRead" = true
    }
}

    Per UpdateItem, la sezione retryMapping ha la seguente struttura. Per una descrizione della update sezione, vedere UpdateItem.

    {
    "update" : {
        "expression" : "someExpression"
        "expressionNames" : {
            "#foo" : "foo"
        },
        "expressionValues" : {
            ":bar" : ... typed value
        }
    },
    "condition": {
        "consistentRead" = true
    }
}

    Per DeleteItem, la sezione retryMapping ha la seguente struttura.

    {
    "condition": {
        "consistentRead" = true
    }
}

    Non c'è modo di specificare operazioni o chiavi diverse su cui lavorare. Il AWS AppSync resolver DynamoDB consente solo di ripetere la stessa operazione sullo stesso oggetto. Inoltre, la sezione condition non consente di specificare un valore per conditionalCheckFailedHandler. Se il nuovo tentativo fallisce, il resolver AWS AppSync DynamoDB segue la strategia. Reject

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 è stata effettuata dajeffTheAdmin, riprova la richiesta, aggiornando l'versionand expectedVersion dall'elemento attualmente 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)
};