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 e o valor atual do objeto no DynamoDB em um data
campo na seção da resposta do GraphQL. error
No entanto, o AWS AppSync resolvedor do DynamoDB oferece alguns recursos adicionais para ajudar os desenvolvedores a lidar com alguns casos extremos comuns:
-
Se AWS AppSync o resolvedor do DynamoDB puder determinar que o valor atual no DynamoDB corresponde ao resultado desejado, ele tratará a operação como se tivesse sido bem-sucedida de qualquer maneira.
-
Em vez de retornar um erro, você pode configurar o resolvedor para invocar uma função Lambda personalizada para decidir como o resolvedor do AWS AppSync DynamoDB deve lidar com a falha.
Isso é descrito com mais detalhes na seção Tratamento de uma falha de verificação da condição.
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:
-
expression
-
A própria expressão de atualização. Para obter mais informações sobre como escrever expressões condicionais, consulte a documentação do ConditionExpressions DynamoDB. Esse campo deve ser especificado.
-
expressionNames
-
As substituições para espaços reservados de nome do atributo da expressão, na forma de pares de chave/valor. A chave corresponde a um espaço reservado de nome usado na expressão e o valor deve ser uma string que corresponde ao nome do atributo do item no DynamoDB. Esse campo é opcional e deve ser preenchido apenas por substituições para espaços reservados de nome do atributo da expressão usados na expressão.
-
expressionValues
-
As substituições para espaços reservados de valor do atributo da expressão, na forma de pares chave-valor. A chave corresponde a um espaço reservado de valor usado na expressão e o valor deve ser um valor digitado. Para obter mais informações sobre como especificar um "valor digitado", consulte Sistema de tipo (Mapeamento de solicitação). Isso deve ser especificado. Esse campo é opcional e deve ser preenchido apenas por substituições para espaços reservados de valor do atributo da expressão usados na expressão.
Os campos restantes informam ao resolvedor do AWS AppSync DynamoDB como lidar com uma falha na verificação de condição:
-
equalsIgnore
-
Quando uma verificação de condição falha ao usar a
PutItem
operação, o resolvedor do AWS AppSync DynamoDB compara o item atualmente no DynamoDB com o item que ele tentou gravar. Se forem os mesmos, ele tratará a operação como bem-sucedida. Você pode usar oequalsIgnore
campo para especificar uma lista de atributos que AWS AppSync devem ser ignorados ao realizar essa comparação. Por exemplo, se a única diferença era um atributoversion
, ele trata a operação como bem-sucedida. Esse campo é opcional. -
consistentRead
-
Quando uma verificação de condição falha, AWS AppSync obtém o valor atual do item do DynamoDB usando uma leitura altamente consistente. Você pode usar esse campo para fazer com que o resolvedor do AWS AppSync DynamoDB use uma leitura eventualmente consistente em vez disso. Esse campo é opcional e usa como padrão
true
. -
conditionalCheckFailedHandler
-
Esta seção permite especificar como o resolvedor do AWS AppSync DynamoDB trata uma falha na verificação de condição depois de comparar o valor atual no DynamoDB com o resultado esperado. Esta seção é opcional. Se omitida, o padrão será uma estratégia de
Reject
.-
strategy
-
A estratégia que o AWS AppSync resolvedor do DynamoDB adota depois de comparar o valor atual no DynamoDB com o resultado esperado. Esse campo é obrigatório e tem os valores possíveis a seguir:
-
Reject
-
A mutação falha e retorna um erro para a mutação e o valor atual do objeto no DynamoDB em um campo
data
na seçãoerror
da resposta do GraphQL. -
Custom
-
O AWS AppSync resolvedor do DynamoDB invoca uma função Lambda personalizada para decidir como lidar com a falha na verificação da condição. Quando
strategy
definido comoCustom
, olambdaArn
campo deve conter a função ARN Lambda a ser invocada.
-
-
lambdaArn
-
A função ARN Lambda a ser invocada determina como o resolvedor do DynamoDB deve lidar com a AWS AppSync falha na verificação da condição. Esse campo deve ser especificado somente quando
strategy
for definida comoCustom
. Para obter mais informações sobre como usar esse atributo, consulte Tratamento de uma falha de verificação da 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 em um data
campo na seção da resposta do GraphQL. error
No entanto, o AWS AppSync resolvedor do DynamoDB oferece alguns recursos adicionais para ajudar os desenvolvedores a lidar com alguns casos extremos comuns:
-
Se AWS AppSync o resolvedor do DynamoDB puder determinar que o valor atual no DynamoDB corresponde ao resultado desejado, ele tratará a operação como se tivesse sido bem-sucedida de qualquer maneira.
-
Em vez de retornar um erro, você pode configurar o resolvedor para invocar uma função Lambda personalizada para decidir como o resolvedor do AWS AppSync DynamoDB deve lidar com a falha.
O fluxograma para esse processo é:
![](images/DynamoDB-condition-check-failure-handling.png)
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:
-
Para a
PutItem
operação, o AWS AppSync resolvedor do DynamoDB compara o valor atual com o que ele tentou gravar, excluindo quaisquer atributos listados na comparação.equalsIgnore
Se os itens forem os mesmos, ele tratará a operação como bem-sucedida e retornará o item recuperado do DynamoDB. Caso contrário, ele seguirá a estratégia configurada.Por exemplo, se o documento de mapeamento da solicitação
PutItem
se parecer com o seguinte:{ "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 o item que está atualmente no DynamoDB se parecer com o seguinte:
{ "id" : { "S" : "1" }, "name" : { "S" : "Steve" }, "version" : { "N" : 8 } }
O AWS AppSync resolvedor do DynamoDB compararia o item que tentou gravar com o valor atual, veria que a única diferença era
version
o campo, mas como está configurado para ignorarversion
o campo, ele considera a operação bem-sucedida e retorna o item que foi recuperado do DynamoDB. -
Para a
DeleteItem
operação, o resolvedor do AWS AppSync DynamoDB verifica se um item foi retornado do DynamoDB. Se nenhum item foi retornado, ele tratará a operação como bem-sucedida. Caso contrário, ele seguirá a estratégia configurada. -
Para a
UpdateItem
operação, o AWS AppSync resolvedor do DynamoDB não tem informações suficientes para determinar se o item atualmente no DynamoDB corresponde ao resultado esperado e, portanto, segue a estratégia configurada.
Se o estado atual do objeto no DynamoDB for diferente do resultado esperado, o resolvedor do AWS AppSync DynamoDB segue 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, e o valor atual do objeto no DynamoDB também é retornado em um data
campo na seção da resposta do GraphQL. error
O item retornado do DynamoDB é enviado ao modelo de mapeamento da resposta para traduzi-lo em um formato que o cliente espera e é filtrado pelo conjunto da seleçã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", "data": { "Name": "Steve", "theVersion": 8 }, ... } ] }
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:
-
reject
a mutação. Isso faz com que o AWS AppSync resolvedor do DynamoDB se comporte como se a estratégia configuradaReject
fosse, retornando um erro para a mutação e o valor atual do objeto no DynamoDB, conforme descrito na seção anterior. -
discard
a mutação. Isso faz com que o AWS AppSync resolvedor do DynamoDB ignore silenciosamente a falha na verificação da condição e retorne o valor no DynamoDB. -
retry
a mutação. Isso faz com que o AWS AppSync resolvedor do DynamoDB repita a mutação com um novo documento de mapeamento de solicitações.
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:
-
arguments
-
Os argumentos da mutação do GraphQL. Isso é o mesmo que os argumentos disponíveis para o documento de mapeamento da solicitação em
$context.arguments
. -
requestMapping
-
O documento de mapeamento da solicitação para essa operação.
-
currentValue
-
O valor atual do objeto no DynamoDB.
-
resolver
-
Informações sobre o AWS AppSync resolvedor.
-
identity
-
Informações sobre o chamador. Isso é o mesmo que as informações de identidade disponíveis para o documento de mapeamento da solicitação em
$context.identity
.
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:
-
reject
a mutação. A carga da resposta para essa opção deve ter a seguinte estrutura:{ "action": "reject" }
Isso faz com que o AWS AppSync resolvedor do DynamoDB se comporte como se a estratégia configurada
Reject
fosse, retornando um erro para a mutação e o valor atual do objeto no DynamoDB, conforme descrito na seção acima. -
discard
a mutação. A carga da resposta para essa opção deve ter a seguinte estrutura:{ "action": "discard" }
Isso faz com que o AWS AppSync resolvedor do DynamoDB ignore silenciosamente a falha na verificação da condição e retorne o valor no DynamoDB.
-
retry
a mutação. A carga da resposta para essa opção deve ter a seguinte estrutura:{ "action": "retry", "retryMapping": { ... } }
Isso faz com que o AWS AppSync resolvedor do DynamoDB repita a mutação com um novo documento de mapeamento de solicitações. A estrutura da seção
retryMapping
depende da operação do DynamoDB e é um subconjunto do documento de mapeamento da solicitação completo para essa operação.Em
PutItem
, a seçãoretryMapping
tem a seguinte estrutura. Para obter uma descrição doattributeValues
campo, consulte PutItem.{ "attributeValues": { ... }, "condition": { "equalsIgnore" = [ ... ], "consistentRead" = true } }
Em
UpdateItem
, a seçãoretryMapping
tem a seguinte estrutura. Para obter uma descrição daupdate
seção, consulte UpdateItem.{ "update" : { "expression" : "someExpression" "expressionNames" : { "#foo" : "foo" }, "expressionValues" : { ":bar" : ... typed value } }, "condition": { "consistentRead" = true } }
Em
DeleteItem
, a seçãoretryMapping
tem a seguinte estrutura.{ "condition": { "consistentRead" = true } }
Não há como especificar uma operação ou chave diferente na qual trabalhar. O AWS AppSync resolvedor do DynamoDB só permite novas tentativas da mesma operação no mesmo objeto. Além disso, a seção
condition
não permite que umconditionalCheckFailedHandler
seja especificado. Se a nova tentativa falhar, o resolvedor do AWS AppSync DynamoDB segue a estratégia.Reject
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) };