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à.

AWS AppSync log delle modifiche del modello di mappatura del resolver

I modelli di mappatura del resolver e della funzione prevedono versioni multiple. La versione del modello di mappatura, ad esempio2018-05-29), impone quanto segue:

Le versioni sono rappresentate utilizzando il YYYY-MM-DD formato, una data successiva corrisponde a una versione più recente. Questa pagina elenca le differenze tra le versioni dei modelli di mappatura attualmente supportate in AWS AppSync.

Disponibilità delle operazioni dell'origine dati per matrice di versione

Nota: solo la versione 2018-05-29 è attualmente supportata nelle funzioni.

Modifica della versione su un modello di mappatura del resolver di unità.

Per i resolver di unità, la versione viene specificata come parte del corpo del modello di mappatura della richiesta. Per aggiornare la versione, è sufficiente aggiornare il campo version alla nuova versione.

Ad esempio, per aggiornare la versione del AWS Lambda modello:

{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "getPost",
        "arguments": $utils.toJson($context.arguments)
    }
}

È necessario aggiornare il campo dalla versione 2017-02-28 alla 2018-05-29 nel seguente modo:

{
    "version": "2018-05-29", ## Note the version
    "operation": "Invoke",
    "payload": {
        "field": "getPost",
        "arguments": $utils.toJson($context.arguments)
    }
}

Modifica della versione su una funzione

Per le funzioni, la versione è specificata come campo functionVersion nell'oggetto della funzione. Per aggiornare la versione, basta aggiornare la functionVersion. Nota: al momento, solo la versione 2018-05-29 è supportata per la funzione.

Di seguito è riportato un esempio di CLI comando per aggiornare la versione di una funzione esistente:

aws appsync update-function \
--api-id REPLACE_WITH_API_ID \
--function-id REPLACE_WITH_FUNCTION_ID \
--data-source-name "PostTable" \
--function-version "2018-05-29" \
--request-mapping-template "{...}" \
--response-mapping-template "\$util.toJson(\$ctx.result)"

Nota: si consiglia di omettere il campo della versione dal modello di mappatura della richiesta di funzione, perché non verrà rispettato. Se non specifichi una versione all'interno del modello di mappatura della richiesta di funzione, il valore della versione verrà sostituito da quello nel campo functionVersion.

2018-05-29

Modifica del comportamento

Ragionamento

Dato il seguente modello di mappatura della risposta:

$util.toJson($ctx.result)

In passato, nella versione 2017-02-28, se $ctx.result tornava null, il modello di mappatura della risposta non veniva eseguito. Con la versione 2018-05-29, ora possiamo gestire questo scenario. Ad esempio, è possibile scegliere di generare un errore di autorizzazione nel modo seguente:

# throw an unauthorized error if the result is null
#if ( $util.isNull($ctx.result) )
    $util.unauthorized()
#end
$util.toJson($ctx.result)

Nota: a volte gli errori restituiti da un'origine dati non sono fatali né previsti, ecco perché il modello di mappatura della risposta deve avere la flessibilità di gestire l'errore di invocazione e decidere se ignorarlo, rigenerarlo o generarne un altro.

Dato il seguente modello di mappatura della risposta:

$util.toJson($ctx.result)

In passato, nella versione 2017-02-28, in caso di un errore di invocazione, veniva valutato il modello di mappatura della risposta e il risultato veniva inserito automaticamente nel blocco errors della risposta GraphQL. Con la versione 2018-05-29, è ora possibile scegliere cosa fare con l'errore, se rigenerarlo, generarne uno diverso o aggiungere l'errore durante la restituzione dei dati.

Rigenerare un errore di invocazione

Nel seguente modello di risposta, generiamo lo stesso errore restituito dall'origine dati.

#if ( $ctx.error )
    $util.error($ctx.error.message, $ctx.error.type)
#end
$util.toJson($ctx.result)

Nel caso di un errore di invocazione (ad esempio se è presente $ctx.error) la risposta è simile alla seguente:

{
    "data": {
        "getPost": null
    },
    "errors": [
        {
            "path": [
                "getPost"
            ],
            "errorType": "DynamoDB:ConditionalCheckFailedException",
            "message": "Conditional check failed exception...",
            "locations": [
                {
                    "line": 5,
                    "column": 5
                }
            ]
        }
    ]
}

Generare un errore diverso

Nel seguente modello di risposta, generiamo lo stesso errore personalizzato dopo aver elaborato l'errore restituito dall'origine dati.

#if ( $ctx.error )
    #if ( $ctx.error.type.equals("ConditionalCheckFailedException") )
        ## we choose here to change the type and message of the error for ConditionalCheckFailedExceptions
        $util.error("Error while updating the post, try again. Error: $ctx.error.message", "UpdateError")
    #else
        $util.error($ctx.error.message, $ctx.error.type)
    #end
#end
$util.toJson($ctx.result)

Nel caso di un errore di invocazione (ad esempio se è presente $ctx.error) la risposta è simile alla seguente:

{
    "data": {
        "getPost": null
    },
    "errors": [
        {
            "path": [
                "getPost"
            ],
            "errorType": "UpdateError",
            "message": "Error while updating the post, try again. Error: Conditional check failed exception...",
            "locations": [
                {
                    "line": 5,
                    "column": 5
                }
            ]
        }
    ]
}

Aggiungere un errore ai dati restituiti

Nel seguente modello di risposta, aggiungiamo lo stesso errore restituito dall'origine dati mentre reinseriamo i dati all'interno della risposta. Questo è noto anche come risposta parziale.

#if ( $ctx.error )
    $util.appendError($ctx.error.message, $ctx.error.type)
    #set($defaultPost = {id: "1", title: 'default post'})
    $util.toJson($defaultPost)
#else
    $util.toJson($ctx.result)
#end

Nel caso di un errore di invocazione (ad esempio se è presente $ctx.error) la risposta è simile alla seguente:

{
    "data": {
        "getPost": {
            "id": "1",
            "title: "A post"
        }
    },
    "errors": [
        {
            "path": [
                "getPost"
            ],
            "errorType": "ConditionalCheckFailedException",
            "message": "Conditional check failed exception...",
            "locations": [
                {
                    "line": 5,
                    "column": 5
                }
            ]
        }
    ]
}

Migrazione dalla versione 2017-02-28 alla 2018-05-29

La migrazione dalla versione 2017-02-28 alla 2018-05-29 è semplice. Modifica il campo della versione nel modello di mappatura della richiesta del resolver o nell'oggetto della versione della funzione. Tuttavia, tieni presente che l'esecuzione della versione 2018-05-29 si comporta in modo diverso dalla 2017-02-28; le modifiche sono evidenziate qui.

Mantenere lo stesso comportamento di esecuzione dalla versione 2017-02-28 alla 2018-05-29

In alcuni casi, è possibile mantenere lo stesso comportamento di esecuzione della versione 2017-02-28 durante l'esecuzione di un modello che ha la versione 2018-05-29.

Esempio: DynamoDB PutItem

Dato il seguente modello di richiesta DynamoDB PutItem del 28/02/2017:

{
    "version" : "2017-02-28",
    "operation" : "PutItem",
    "key": {
        "foo" : ... typed value,
        "bar" : ... typed value
    },
    "attributeValues" : {
        "baz" : ... typed value
    },
    "condition" : {
       ...
    }
}

E il seguente modello di risposta:

$util.toJson($ctx.result)

La migrazione alla versione 2018-05-29 modifica questi modelli nel modo seguente:

{
    "version" : "2018-05-29", ## Note the new 2018-05-29 version
    "operation" : "PutItem",
    "key": {
        "foo" : ... typed value,
        "bar" : ... typed value
    },
    "attributeValues" : {
        "baz" : ... typed value
    },
    "condition" : {
       ...
    }
}

E modifica il modello di risposta nel modo seguente:

## If there is a datasource invocation error, we choose to raise the same error
## the field data will be set to null.
#if($ctx.error)
  $util.error($ctx.error.message, $ctx.error.type, $ctx.result)
#end

## If the data source invocation is null, we return null.
#if($util.isNull($ctx.result))
  #return
#end

$util.toJson($ctx.result)

Ora che hai la responsabilità di gestire gli errori, abbiamo scelto di generare lo stesso errore utilizzando $util.error() che è stato restituito da DynamoDB. Puoi adattare questo frammento per convertire il modello di mappatura alla versione 2018-05-29, ma devi ricordare che se il modello di risposta è diverso dovrai tenere conto delle modifiche al comportamento di esecuzione.

Esempio: DynamoDB GetItem

Dato il seguente modello di richiesta DynamoDB GetItem del 28/02/2017:

{
    "version" : "2017-02-28",
    "operation" : "GetItem",
    "key" : {
        "foo" : ... typed value,
        "bar" : ... typed value
    },
    "consistentRead" : true
}

E il seguente modello di risposta:

## map table attribute postId to field Post.id
$util.qr($ctx.result.put("id", $ctx.result.get("postId")))

$util.toJson($ctx.result)

La migrazione alla versione 2018-05-29 modifica questi modelli nel modo seguente:

{
    "version" : "2018-05-29", ## Note the new 2018-05-29 version
    "operation" : "GetItem",
    "key" : {
        "foo" : ... typed value,
        "bar" : ... typed value
    },
    "consistentRead" : true
}

E modifica il modello di risposta nel modo seguente:

## If there is a datasource invocation error, we choose to raise the same error
#if($ctx.error)
  $util.error($ctx.error.message, $ctx.error.type)
#end

## If the data source invocation is null, we return null.
#if($util.isNull($ctx.result))
  #return
#end

## map table attribute postId to field Post.id
$util.qr($ctx.result.put("id", $ctx.result.get("postId")))

$util.toJson($ctx.result)

Nella versione 2017-02-28, se l'invocazione dell'origine dati era null, cioè non c'era alcuna voce nella tabella DynamoDB che corrispondeva alla nostra chiave, il modello di mappatura della risposta non sarebbe stato eseguito. Questo poteva andare bene nella maggior parte dei casi, ma se prevedevi che $ctx.result non fosse null, questo scenario deve essere gestito.

2017-02-28

Caratteristiche