As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Expressões de condição

Quando objetos sofrem mutação no DynamoDB usando as operações PutItem, UpdateItem e DeleteItem do DynamoDB, opcionalmente, é possível especificar uma expressão de condição que controla se a solicitação deve ser bem-sucedida ou não, com base no estado do objeto que já está no DynamoDB antes que a operação seja realizada.

O AWS AppSync resolvedor do DynamoDB permite que uma expressão de condição seja especificada PutItem emUpdateItem,, DeleteItem e solicite documentos de mapeamento, além de uma estratégia a ser seguida se a condição falhar e o objeto não for atualizado.

Exemplo 1

O documento de mapeamento PutItem a seguir não tem uma expressão de condição. Como resultado, ele coloca um item no DynamoDB mesmo se um item com a mesma chave já existir, sobrescrevendo o item existente.

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

Exemplo 2

O seguinte documento de mapeamento PutItem possui uma expressão de condição que permite que a operação seja bem-sucedida somente se um item com a mesma chave não existir no DynamoDB.

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

Por padrão, se a verificação da condição falhar, o resolvedor do AWS AppSync DynamoDB retornará um erro para a mutação. No entanto, o AWS AppSync resolvedor do DynamoDB oferece alguns recursos adicionais para ajudar os desenvolvedores a lidar com alguns casos extremos comuns:

Isso é descrito com mais detalhes na seção Tratamento de uma falha de verificação da condição.

Para obter mais informações sobre as expressões de condições do DynamoDB, consulte a documentação do DynamoDB. ConditionExpressions

Especificação de uma condição

Os documentos de mapeamento da solicitação PutItem, UpdateItem e DeleteItem permitem que uma seção condition opcional seja especificada. Se omitida, nenhuma verificação de condição é feita. Se especificada, a condição deve ser verdadeira para que a operação seja bem-sucedida.

A seção condition tem a seguinte estrutura:

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

Os campos a seguir especificam a condição:

Os campos restantes informam ao resolvedor do AWS AppSync DynamoDB como lidar com uma falha na verificação de condição:

Tratamento de uma falha de verificação da condição

Por padrão, quando uma verificação de condição falha, o resolvedor do AWS AppSync DynamoDB retorna um erro para a mutação e o valor atual do objeto no DynamoDB. No entanto, o AWS AppSync resolvedor do DynamoDB oferece alguns recursos adicionais para ajudar os desenvolvedores a lidar com alguns casos extremos comuns:

O fluxograma para esse processo é:

Verificação do resultado desejado

Quando a verificação da condição falha, o resolvedor do AWS AppSync DynamoDB executa uma solicitação do GetItem DynamoDB para obter o valor atual do item do DynamoDB. Por padrão, ele usa uma leitura fortemente consistente, mas isso pode ser configurado usando o campo consistentRead no bloco condition e compará-lo com o resultado esperado:

Se o estado atual do objeto no DynamoDB for diferente do resultado esperado, o resolvedor do AWS AppSync DynamoDB seguirá a estratégia configurada para rejeitar a mutação ou invocar uma função Lambda para determinar o que fazer a seguir.

Seguir a estratégia "Rejeitar"

Ao seguir a Reject estratégia, o resolvedor do AWS AppSync DynamoDB retorna um erro para a mutação.

Por exemplo, considere a solicitação de mutação a seguir:

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

Se o item retornado do DynamoDB for semelhante ao seguinte:

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

E o modelo de mapeamento de resposta é semelhante ao seguinte:

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

A resposta do GraphQL é semelhante à seguinte:

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

Além disso, se qualquer campo no objeto retornado for preenchido por outros resolvedores e a mutação foi bem-sucedida, eles não serão resolvidos quando o objeto for retornado na seção error.

Seguir a estratégia "Personalizada"

Ao seguir a Custom estratégia, o resolvedor do AWS AppSync DynamoDB invoca uma função Lambda para decidir o que fazer em seguida. A Função Lambda escolhe um destas opções a seguir:

A solicitação de invocação do Lambda

O AWS AppSync resolvedor do DynamoDB invoca a função Lambda especificada no. lambdaArn Ele usa o mesmo service-role-arn configurado na fonte de dados. A carga da invocação tem a seguinte estrutura:

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

Os campos são definidos da seguinte forma:

Um exemplo completo da carga:

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

A resposta de invocação do Lambda

A função Lambda pode inspecionar a carga de invocação e aplicar qualquer lógica de negócios para decidir como o resolvedor do DynamoDB deve lidar com a falha AWS AppSync . Existem três opções para tratamento da falha de verificação da condição:

Veja aqui um exemplo de função do Lambda para lidar com uma solicitação PutItem com falha. A lógica de negócios analisa quem fez a chamada. Se foi feita pelo jeffTheAdmin, ela tentará novamente a solicitação, atualizando version e expectedVersion do item atualmente no DynamoDB. Caso contrário, ela rejeitará a mutação.

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