Expresiones de condición - AWS AppSync
Ejemplo 1Ejemplo 2Especificación de una condiciónGestión de un error de comprobación de la condición

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Expresiones de condición

Al mutar objetos en DynamoDB utilizando las operaciones de DynamoDB PutItem, UpdateItem y DeleteItem, puede especificar opcionalmente una expresión de condición que determine si la solicitud se debe atender o no en función del estado del objeto que ya está en DynamoDB antes de ejecutar la operación.

El solucionador de AWS AppSync DynamoDB permite especificar una expresión de condición PutItem en UpdateItem los documentos de mapeo DeleteItem y solicitarlos, así como una estrategia a seguir si la condición falla y el objeto no se ha actualizado.

Ejemplo 1

El siguiente documento de mapeo PutItem no tiene una expresión de condición. Como resultado, pone un elemento en DynamoDB incluso si ya existe un elemento con la misma clave, lo que permite sobrescribir el elemento existente.

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

Ejemplo 2

El siguiente documento de mapeo PutItem tiene una expresión de condición que permitirá que la operación se complete solo si no existe un elemento con la misma clave en DynamoDB.

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

De forma predeterminada, si se produce un error en la comprobación de condición, el solucionador de AWS AppSync DynamoDB devuelve un error para la mutación y el valor actual del objeto en DynamoDB en un data campo de la sección de la respuesta de GraphQL. error Sin embargo, el solucionador de AWS AppSync DynamoDB ofrece algunas funciones adicionales para ayudar a los desarrolladores a gestionar algunos casos extremos comunes:

  • Si el solucionador de AWS AppSync DynamoDB puede determinar que el valor actual de DynamoDB coincide con el resultado deseado, considerará la operación como si se hubiera realizado correctamente de todos modos.

  • En lugar de devolver un error, puede configurar el solucionador para que invoque una función Lambda personalizada a fin de decidir cómo debe gestionar el fallo el solucionador de AWS AppSync DynamoDB.

Estos casos se describen con más detalle en la sección de gestión de un error de comprobación de la condición.

Para obtener más información sobre las expresiones de condiciones de DynamoDB, consulte la documentación de DynamoDB. ConditionExpressions

Especificación de una condición

Todos los documentos de mapeo de solicitudes PutItem, UpdateItem y DeleteItem permiten especificar una sección condition opcional. Si se omite, no se comprobará ninguna condición. Si se especifica, la condición debe ser true para que la operación se lleve a cabo correctamente.

Las secciones condition tienen la siguiente estructura:

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

Los campos siguientes especifican la condición:

expression

La misma expresión de actualización. Para obtener más información sobre cómo escribir expresiones de condiciones, consulte la documentación de ConditionExpressions DynamoDB. Este campo debe especificarse.

expressionNames

Las sustituciones de los marcadores de posición de nombre de atributo de expresión, en forma de pares de clave-valor. La clave corresponde a un marcador de posición de nombre usado en la expresión, y el valor tiene que ser una cadena que corresponda al nombre de atributo del elemento en DynamoDB. Este campo es opcional y solo debe rellenarse con las sustituciones de los marcadores de posición de nombre de atributo de expresión que se usen en la expresión.

expressionValues

Las sustituciones de los marcadores de posición de valor de atributo de expresión, en forma de pares de clave-valor. La clave corresponde a un marcador de posición de valor usado en la expresión y el valor tiene que ser un valor con tipo. Para obtener más información sobre cómo especificar un “valor con tipo”, consulte Sistema de tipos (mapeo de solicitud). Este valor debe especificarse. Este campo es opcional y solo debe rellenarse con las sustituciones de los marcadores de posición de valor de atributo de expresión que se usen en la expresión.

Los campos restantes indican al solucionador de AWS AppSync DynamoDB cómo gestionar un error en la comprobación de estado:

equalsIgnore

Cuando se produce un error en una comprobación de estado al utilizar la PutItem operación, el solucionador de AWS AppSync DynamoDB compara el elemento que se encuentra actualmente en DynamoDB con el elemento que intentó escribir. Si son iguales, trata la operación como si se hubiera realizado correctamente. Puede usar el equalsIgnore campo para especificar una lista de atributos que AWS AppSync debe omitir al realizar la comparación. Por ejemplo, si la única diferencia ha sido un atributo version, trata la operación como si se hubiera realizado satisfactoriamente. Este campo es opcional.

consistentRead

Cuando se produce un error en una comprobación de estado, AWS AppSync obtiene el valor actual del elemento de DynamoDB mediante una lectura muy coherente. Puede usar este campo para indicar al solucionador de AWS AppSync DynamoDB que utilice en su lugar una lectura eventualmente coherente. Este campo es opcional y de forma predeterminada es true.

conditionalCheckFailedHandler

En esta sección, puede especificar el modo en que el solucionador de AWS AppSync DynamoDB trata un error de comprobación de condición después de comparar el valor actual de DynamoDB con el resultado esperado. Esta sección es opcional. Si se omite, el valor predeterminado es una estrategia Reject.

strategy

La estrategia que adopta el solucionador de AWS AppSync DynamoDB después de comparar el valor actual de DynamoDB con el resultado esperado. Este campo es obligatorio y tiene los siguientes valores posibles:

Reject

La mutación fracasa y se obtiene un error y un error para la mutación y el valor actual del objeto en DynamoDB en un campo data de la sección error de la respuesta de GraphQL.

Custom

El solucionador de AWS AppSync DynamoDB invoca una función Lambda personalizada para decidir cómo gestionar el error de comprobación de estado. Cuando strategy se establece enCustom, el lambdaArn campo debe contener la ARN función Lambda que se va a invocar.

lambdaArn

La función ARN de Lambda que se va a invocar y que determina cómo debe gestionar la resolución de DynamoDB el AWS AppSync error de comprobación de estado. Este campo solo tiene que especificarse cuando strategy tiene el valor Custom. Para obtener más información acerca de cómo utilizar esta característica, consulte la sección Gestión de los casos en que no se cumple la condición.

Gestión de un error de comprobación de la condición

De forma predeterminada, cuando se produce un error en una comprobación de condición, el solucionador de AWS AppSync DynamoDB devuelve un error para la mutación y el valor actual del objeto en DynamoDB en un data campo de la sección de la respuesta de GraphQL. error Sin embargo, el solucionador de AWS AppSync DynamoDB ofrece algunas funciones adicionales para ayudar a los desarrolladores a gestionar algunos casos extremos comunes:

  • Si el solucionador de AWS AppSync DynamoDB puede determinar que el valor actual de DynamoDB coincide con el resultado deseado, considerará la operación como si se hubiera realizado correctamente de todos modos.

  • En lugar de devolver un error, puede configurar el solucionador para que invoque una función Lambda personalizada a fin de decidir cómo debe gestionar el fallo el solucionador de AWS AppSync DynamoDB.

El diagrama de flujo de este proceso es:

Comprobación del resultado deseado

Cuando se produce un error en la comprobación de estado, el AWS AppSync solucionador de DynamoDB realiza una solicitud de GetItem DynamoDB para obtener el valor actual del elemento de DynamoDB. De forma predeterminada, utiliza una lectura altamente coherente; sin embargo, esto puede configurarse mediante el campo consistentRead en el bloque condition y compararlo con el resultado esperado:

  • Para la PutItem operación, el solucionador de AWS AppSync DynamoDB compara el valor actual con el que intentó escribir, excluyendo todos los atributos incluidos equalsIgnore en la comparación. Si los elementos son los mismos, trata la operación como si se hubiera realizado y devuelve el elemento obtenido de DynamoDB. De lo contrario, sigue la estrategia configurada.

    Por ejemplo, si el documento de mapeo de PutItem tenía el siguiente aspecto:

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

    Y el elemento que está actualmente en DynamoDB fuese de la siguiente manera:

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

    El solucionador de AWS AppSync DynamoDB comparaba el elemento que intentaba escribir con el valor actual y comprobaba que la única diferencia era version el campo, pero como está configurado para ignorar el campo, considera que version la operación se ha realizado correctamente y devuelve el elemento que se ha recuperado de DynamoDB.

  • Para la DeleteItem operación, el solucionador de AWS AppSync DynamoDB comprueba que DynamoDB ha devuelto un elemento. Si no se devuelve ningún elemento, trata la operación como si se hubiera realizado correctamente. De lo contrario, sigue la estrategia configurada.

  • Para la UpdateItem operación, el solucionador de AWS AppSync DynamoDB no tiene suficiente información para determinar si el elemento que se encuentra actualmente en DynamoDB coincide con el resultado esperado y, por lo tanto, sigue la estrategia configurada.

Si el estado actual del objeto en DynamoDB es diferente del resultado esperado, el solucionador de AWS AppSync DynamoDB sigue la estrategia configurada: rechazar la mutación o invocar una función Lambda para determinar qué hacer a continuación.

Aplicación de la estrategia de rechazo

Al seguir la Reject estrategia, el solucionador de AWS AppSync DynamoDB devuelve un error para la mutación y el valor actual del objeto en DynamoDB también se devuelve en un data campo de la sección de la respuesta de GraphQL. error El elemento que se devuelve desde DynamoDB pasa por la plantilla de mapeo de respuesta para convertirlo a un formato que el cliente espera y también se filtra según el conjunto de selección.

Por ejemplo, si se recibe la solicitud de mutación siguiente:

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

Si el elemento devuelto de DynamoDB tiene un aspecto similar al siguiente:

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

Y la plantilla de mapeo de respuesta es como se muestra a continuación:

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

La respuesta GraphQL tiene este aspecto:

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

Además, si hay algún campo en el objeto devuelto que hayan cumplimentado otros solucionadores y si la mutación se ha efectuado satisfactoriamente, el objeto no se resuelve cuando se devuelve en la sección error.

Aplicación de la estrategia personalizada

Al seguir la Custom estrategia, el solucionador de AWS AppSync DynamoDB invoca una función Lambda para decidir qué hacer a continuación. La función Lambda selecciona una de las siguientes opciones:

  • reject para la mutación. Esto indica al solucionador de AWS AppSync DynamoDB que se comporte como si la estrategia configurada lo Reject estuviera, devolviendo un error para la mutación y el valor actual del objeto en DynamoDB, tal y como se describe en la sección anterior.

  • discard para la mutación. Esto indica al solucionador de AWS AppSync DynamoDB que ignore silenciosamente el error de comprobación de estado y devuelve el valor en DynamoDB.

  • retry para la mutación. Esto indica al solucionador de AWS AppSync DynamoDB que vuelva a intentar la mutación con un nuevo documento de mapeo de solicitudes.

La solicitud de invocación Lambda

El AWS AppSync solucionador de DynamoDB invoca la función Lambda especificada en. lambdaArn Se utiliza el mismo service-role-arn configurado en el origen de datos. La carga de la invocación tiene la siguiente estructura:

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

Los campos se definen de la siguiente manera:

arguments

Los argumentos de la mutación de GraphQL. Esto es lo mismo que los argumentos disponibles en el documento de mapeo de solicitudes en $context.arguments.

requestMapping

El documento de mapeo de solicitudes de esta operación.

currentValue

El valor actual del objeto en DynamoDB.

resolver

Información sobre el solucionador. AWS AppSync

identity

Información sobre el intermediario. Se trata de la información de identidad disponible en el documento de mapeo de solicitudes en $context.identity.

Un ejemplo completo de la 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"
    }
}

La respuesta de invocación Lambda

La función Lambda puede inspeccionar la carga útil de invocación y aplicar cualquier lógica empresarial para decidir cómo debe gestionar el fallo el solucionador de AWS AppSync DynamoDB. Existen tres opciones para gestionar el error de comprobación de condición:

  • reject para la mutación. La carga de respuesta de esta opción debe tener esta estructura:

    {
    "action": "reject"
}

    Esto indica al solucionador de AWS AppSync DynamoDB que se comporte como si la estrategia configurada lo Reject estuviera, devolviendo un error para la mutación y el valor actual del objeto en DynamoDB, tal y como se describe en la sección anterior.

  • discard para la mutación. La carga de respuesta de esta opción debe tener esta estructura:

    {
    "action": "discard"
}

    Esto indica al solucionador de AWS AppSync DynamoDB que ignore silenciosamente el error de comprobación de estado y devuelve el valor en DynamoDB.

  • retry para la mutación. La carga de respuesta de esta opción debe tener esta estructura:

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

    Esto indica al solucionador de AWS AppSync DynamoDB que vuelva a intentar la mutación con un nuevo documento de mapeo de solicitudes. La estructura de la sección retryMapping depende de la operación de DynamoDB y es un subconjunto del documento de mapeo de solicitudes completo de esa operación.

    Para PutItem, la sección retryMapping tiene la siguiente estructura. Para obtener una descripción del attributeValues campo, consulte. PutItem

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

    Para UpdateItem, la sección retryMapping tiene la siguiente estructura. Para obtener una descripción de la update sección, consulte UpdateItem.

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

    Para DeleteItem, la sección retryMapping tiene la siguiente estructura.

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

    No hay forma de especificar otra operación o clave en la que trabajar. El solucionador de AWS AppSync DynamoDB solo permite reintentos de la misma operación en el mismo objeto. Asimismo, la sección condition no permite especificar un conditionalCheckFailedHandler. Si se produce un error en el reintento, el solucionador de AWS AppSync DynamoDB sigue la estrategia. Reject

A continuación se muestra un ejemplo de función Lambda para tratar una solicitud PutItem sin éxito. La lógica de negocio examina quién realizó la llamada. Si la realizó jeffTheAdmin, vuelve a intentar realizar la solicitud, actualizando version y expectedVersion desde el elemento actualmente en DynamoDB. De lo contrario, rechaza la mutación.

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