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à. # Operazioni di controllo delle versioni, rilevamento dei conflitti e sincronizzazione per le sorgenti dati DynamoDB in AWS AppSync AWS AppSyncle funzionalità avanzate di gestione dei dati per DynamoDB sfruttano tre funzionalità chiave: origini dati con versione, rilevamento e risoluzione dei conflitti e operazioni di sincronizzazione. Questi strumenti consentono applicazioni robuste e scalabili che gestiscono in modo efficiente le modifiche e la sincronizzazione simultanee dei dati in ambienti distribuiti. Le fonti di dati con versioni diverse costituiscono la base del sistema di gestione dei dati di AWS AppSync The Data Management. Questa funzionalità migliora automaticamente gli elementi di DynamoDB con metadati di controllo delle versioni, registra le modifiche apportate AWS AppSync dalle mutazioni a una tabella Delta e mantiene le «lapidi» per gli elementi eliminati. Gli sviluppatori possono configurare i periodi di conservazione degli elementi eliminati e dei log delle modifiche, ottimizzando l'archiviazione e garantendo al contempo la coerenza dei dati. Le fonti di dati con versioni semplificano l'implementazione delle operazioni di rilevamento e sincronizzazione dei conflitti, fornendo una solida base per la gestione avanzata dei dati. I meccanismi di rilevamento e risoluzione dei conflitti salvaguardano l'integrità dei dati quando si verificano scritture simultanee. AWS AppSync offre tre strategie: Optimistic Concurrency, Automerge e Risoluzione basata su Lambda. Optimistic Concurrency rifiuta le mutazioni contrastanti, consentendo ai clienti di riprovare con dati aggiornati. Automerge risolve automaticamente i conflitti in base ai tipi di dati, alla fusione di elenchi, all'esecuzione di unioni di set e alla conservazione dei valori scalari esistenti. La risoluzione basata su Lambda consente una logica personalizzata per scenari di conflitto complessi. Queste opzioni offrono agli sviluppatori flessibilità nella gestione dei conflitti di dati, garantendo la coerenza tra i sistemi distribuiti. Le operazioni di sincronizzazione consentono il recupero e l'aggiornamento efficienti dei dati nelle applicazioni client. Questa funzionalità consente ai client di recuperare tutti i risultati da una tabella DynamoDB e successivamente recuperare solo i dati modificati dall'ultima query. AWS AppSync determina se accedere alla tabella Base o alla tabella Delta in base al token di sincronizzazione fornito, ottimizzando le prestazioni e riducendo il trasferimento dei dati. **Topics** + [Controllo delle versioni delle sorgenti dati DynamoDB](versioned-data-sources.md) + [Rilevamento e risoluzione dei conflitti](conflict-detection-and-resolution.md) + [Utilizzo delle operazioni di sincronizzazione di DynamoDB su sorgenti dati con versioni](aws-appsync-conflict-detection-and-sync-sync-operations.md) # Controllo delle versioni delle sorgenti dati DynamoDB in AWS AppSync AWS AppSync attualmente supporta il controllo delle versioni su sorgenti dati DynamoDB. Le operazioni di rilevamento dei conflitti, risoluzione dei conflitti e sincronizzazione richiedono un'origine dati `Versioned`. Quando abiliti il controllo delle versioni su un'origine dati, automaticamente: AWS AppSync + Migliorare gli elementi con i metadati del controllo delle versioni degli oggetti. + Registra le modifiche apportate agli elementi con AWS AppSync mutazioni in una tabella *Delta*. + Gestire gli elementi eliminati nella tabella *Base* con una "rimozione definitiva" per un periodo di tempo configurabile. ## Configurazione dell'origine dati con versione Quando si attivano le versioni multiple in un'origine dati DynamoDB, specificare i seguenti campi: ** `BaseTableTTL` ** Il numero di minuti per mantenere gli elementi eliminati nella tabella *Base* con una "rimozione definitiva", un campo di metadati che indica che l'elemento è stato eliminato. È possibile impostare questo valore su *0* se si desidera che gli elementi vengano rimossi immediatamente quando vengono eliminati. Questo campo è obbligatorio. ** `DeltaSyncTableName` ** Il nome della tabella in cui vengono archiviate le modifiche apportate agli elementi con AWS AppSync mutazioni. Questo campo è obbligatorio. ** `DeltaSyncTableTTL` ** Numero di minuti per conservare gli elementi nella tabella *Delta*. Questo campo è obbligatorio. ## Registrazione della tabella Delta Sync AWS AppSync attualmente supporta Delta Sync Logging for mutations using `PutItem``UpdateItem`, e le operazioni DynamoDB`DeleteItem`. Quando una AWS AppSync mutazione modifica un elemento in un'origine dati con versione, un record di tale modifica verrà archiviato in una tabella *Delta* ottimizzata per gli aggiornamenti incrementali. Puoi scegliere di utilizzare diverse tabelle *Delta* (ad esempio una per tipo, una per area di dominio) per altre fonti di dati con versione o una singola tabella *Delta* per la tua API. AWS AppSync sconsiglia di utilizzare una singola tabella *Delta* per più tabelle per APIs evitare la collisione delle chiavi primarie. Lo schema richiesto per questa tabella è il seguente: ** `ds_pk` ** Valore stringa utilizzato come chiave di partizione. È costruito concatenando il nome della fonte di dati di *base* e il formato ISO 8601 della data in cui è avvenuta la modifica (ad es.). `Comments:2019-01-01` *Quando il `customPartitionKey` flag del modello di mappatura VTL è impostato come nome di colonna della chiave di partizione (vedi [Resolver Mapping Template Reference for DynamoDB](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem) nella *Developer Guide),AWS AppSync il* formato `ds_pk` delle modifiche e la stringa viene costruita aggiungendole il valore della chiave di partizione nel nuovo record nella tabella Base.* Ad esempio, se il record nella tabella *Base* ha un valore di chiave di partizione `1a` e un valore di chiave di ordinamento di`2b`, il nuovo valore della stringa sarà:`Comments:2019-01-01:1a`. ** `ds_sk` ** Un valore stringa utilizzato come chiave di ordinamento. Viene costruito concatenando il formato ISO 8601 dell'ora in cui è avvenuta la modifica, la chiave primaria dell'elemento e la versione dell'elemento. La combinazione di questi campi garantisce l'unicità di ogni voce nella tabella *Delta* (ad esempio, per l'ora di, l'ID `09:30:00` e la versione di `1a``2`, questo sarebbe). `09:30:00:1a:2` *Quando il `customPartitionKey` flag del modello di mappatura VTL è impostato sul nome della colonna della chiave di partizione (vedi [Resolver Mapping Template Reference for DynamoDB](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem) nella *Developer Guide),AWS AppSync il* formato `ds_sk` delle modifiche e la stringa viene costruita sostituendo il valore della chiave combinata con il valore della chiave di ordinamento nella tabella Base.* Utilizzando l'esempio precedente, se il record nella tabella *Base* ha un valore di chiave di partizione `1a` e un valore di chiave di ordinamento di`2b`, il nuovo valore della stringa sarà:`09:30:00:2b:3`. ** `_ttl` ** Un valore numerico che memorizza il timestamp, in secondi dall'epoca, quando un elemento deve essere rimosso dalla tabella *Delta*. Questo valore viene determinato aggiungendo il valore `DeltaSyncTableTTL` configurato nell'origine dati nel momento in cui si è verificata la modifica. Questo campo deve essere configurato come Attributo TTL DynamoDB. Il ruolo IAM configurato per l'utilizzo con la tabella *Base* deve contenere anche le autorizzazioni per operare nella tabella *Delta*. In questo esempio, viene visualizzato il criterio delle autorizzazioni per una tabella *Base* denominata `Comments` e una tabella *Delta* denominata `ChangeLog`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:UpdateItem" ], "Resource": [ "arn:aws:dynamodb:us-east-1:000000000000:table/Comments", "arn:aws:dynamodb:us-east-1:000000000000:table/Comments/*", "arn:aws:dynamodb:us-east-1:000000000000:table/ChangeLog", "arn:aws:dynamodb:us-east-1:000000000000:table/ChangeLog/*" ] } ] } ``` ------ ## Metadati dell'origine dati con versione AWS AppSync gestisce i campi di metadati sulle fonti di `Versioned` dati per tuo conto. La modifica di questi campi può causare errori nell'applicazione o perdita di dati. Questi campi includono: ** `_version` ** Un contatore monotonicamente crescente che viene aggiornato ogni volta che si apporta una modifica a un elemento. ** `_lastChangedAt` ** Un valore numerico che memorizza il timestamp, in millisecondi dall'epoca, al momento dell'ultima modifica di un elemento. ** `_deleted` ** Un valore booleano "contrassegnato per la rimozione definitiva" che indica che un elemento è stato eliminato. Questo può essere utilizzato dalle applicazioni per rimuovere gli elementi eliminati dagli archivi dati locali. ** `_ttl` ** Un valore numerico che memorizza il timestamp, in secondi dall'epoca, quando un elemento deve essere rimosso dall'origine dati sottostante. ** `ds_pk` ** Valore stringa utilizzato come chiave di partizione per le tabelle *Delta*. ** `ds_sk` ** Valore stringa utilizzato come chiave di ordinamento per le tabelle *Delta*. **`gsi_ds_pk`** Un attributo di valore di stringa generato per supportare un indice secondario globale come chiave di partizione. *Verrà incluso solo se entrambi i `populateIndexFields` flag `customPartitionKey` e sono abilitati nel modello di mappatura VTL (vedi [Resolver Mapping Template Reference for DynamoDB nella Developer](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem) Guide).AWS AppSync * *Se abilitato, il valore verrà costruito concatenando il nome della fonte di dati di *Base* e il formato ISO 8601 della data in cui è avvenuta la modifica (ad esempio se la tabella *Base* è denominata Comments, questo record verrà impostato come).* `Comments:2019-01-01` **`gsi_ds_sk`** Un attributo di valore di stringa generato per supportare un indice secondario globale come chiave di ordinamento. *Verrà incluso solo se entrambi i `populateIndexFields` flag `customPartitionKey` e sono abilitati nel modello di mappatura VTL (vedi [Resolver Mapping Template Reference for DynamoDB nella Developer](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem) Guide).AWS AppSync * Se abilitato, il valore verrà costruito concatenando il formato ISO 8601 dell'ora in cui è avvenuta la modifica, la chiave di partizione dell'elemento nella tabella *Base*, la chiave di ordinamento dell'elemento nella tabella *Base* e la versione dell'elemento (ad esempio per un periodo di`09:30:00`, un valore della chiave di partizione di`1a`, un valore della chiave di ordinamento di `2b` e la versione di`3`, questo sarebbe`09:30:00:1a#2b:3`). Questi campi di metadati influiranno sulla dimensione complessiva degli elementi nell'origine dati sottostante. AWS AppSync consiglia di riservare una *dimensione massima di archiviazione di 500 byte o più della chiave primaria* per i metadati delle origini dati con versioni diverse durante la progettazione dell'applicazione. Per utilizzare questi metadati nelle applicazioni client, includere i campi `_version`, `_lastChangedAt` e `_deleted` nei tipi GraphQL e nel set di selezione per le mutazioni. # Rilevamento e risoluzione dei conflitti in AWS AppSync Quando vengono eseguite scritture simultanee con AWS AppSync, è possibile configurare le strategie di rilevamento e risoluzione dei conflitti per gestire gli aggiornamenti in modo appropriato. Il rilevamento dei conflitti determina se la mutazione è in conflitto con l'elemento scritto effettivo nell'origine dati. Il rilevamento dei conflitti viene abilitato impostando il SyncConfig valore nel `conflictDetection` campo su. `VERSION` La risoluzione dei conflitti è l'azione che viene eseguita nel caso in cui venga rilevato un conflitto. Ciò viene determinato impostando il campo Conflict Handler nel SyncConfig. Esistono tre strategie di risoluzione dei conflitti: + OPTIMISTIC\$1CONCURRENCY + AUTOMERGE + LAMBDA Le versioni vengono incrementate automaticamente AWS AppSync durante le operazioni di scrittura e non devono essere modificate dai client o dall'esterno di un resolver configurato con un'origine dati abilitata alla versione. Ciò cambierà il comportamento di coerenza del sistema e potrebbe comportare la perdita di dati. ## Concorrenza ottimistica Optimistic Concurrency è una strategia di risoluzione dei conflitti che AWS AppSync prevede fonti di dati con versioni diverse. Quando il risolutore dei conflitti è impostato su Optimistic Concurrency, se viene rilevata una mutazione in ingresso per avere una versione diversa dalla versione effettiva dell'oggetto, il gestore dei conflitti rifiuterà semplicemente la richiesta in ingresso. All'interno della risposta GraphQL, verrà fornito l'elemento esistente sul server con la versione più recente. Il client dovrebbe quindi gestire questo conflitto localmente e riprovare la mutazione con la versione aggiornata dell'elemento. ## Si fonde automaticamente Automerge offre agli sviluppatori un modo semplice per configurare una strategia di risoluzione dei conflitti senza scrivere logica lato client per unire manualmente i conflitti che non erano in grado di essere gestiti da altre strategie. Automerge aderisce a un set di regole rigoroso quando si uniscono i dati per risolvere i conflitti. I principi di Automerge ruotano attorno al tipo di dati sottostante del campo GraphQL. Essi sono i seguenti: + Conflitto su un campo scalare: scalare GraphQL o qualsiasi campo che non sia una raccolta (ad esempio List, Set, Map). Rifiuto del valore in ingresso per il campo scalare e selezione del valore esistente nel server. + Conflitto su un elenco: il tipo GraphQL e il tipo di database sono elenchi. Concatenamento dell'elenco in entrata con l'elenco esistente nel server. I valori di elenco nella mutazione in arrivo verranno aggiunti alla fine dell'elenco nel server. I valori duplicati verranno mantenuti. + Conflitto su un set: il tipo GraphQL è un elenco e il tipo di database è un set. Applicazione di un insieme unione utilizzando il set in ingresso e il set esistente nel server. Questo aderisce alle proprietà di un set, vale a dire nessuna voce duplicata. + Quando una mutazione in arrivo aggiunge un nuovo campo all'elemento o viene creata su un campo con il valore di`null`, uniscilo all'elemento esistente. + Conflitto su una mappa: quando il tipo di dati sottostante nel database è una mappa (ad esempio documento chiave-valore), applicare le regole di cui sopra mentre analizza ed elabora ciascuna proprietà della mappa. Automerge è progettato per rilevare, unire e riprovare automaticamente le richieste con una versione aggiornata, assolvendo il client dalla necessità di unire manualmente i dati in conflitto. Per mostrare un esempio di come Automerge gestisce un conflitto su un tipo scalare. Useremo il seguente record come punto di partenza. ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "_version" : 4 } ``` Ora una mutazione in arrivo potrebbe tentare di aggiornare l'elemento ma con una versione precedente poiché il client non è ancora sincronizzato con il server. Dovrebbe essere simile a questo: ``` { "id" : 1, "name" : "Nadia", "jersey" : 55, "_version" : 2 } ``` Si noti la versione obsoleta di 2 nella richiesta in entrata. Durante questo flusso, Automerge unirà i dati rifiutando l'aggiornamento del campo "jersey" a "55" e manterrà il valore a "5" con conseguente salvataggio della seguente immagine dell'elemento nel server. ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "_version" : 5 # version is incremented every time automerge performs a merge that is stored on the server. } ``` Dato lo stato dell'elemento mostrato sopra alla versione 5, ora supponiamo che una mutazione in entrata tenti di cambiare l'elemento con la seguente immagine: ``` { "id" : 1, "name" : "Shaggy", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner"] # underlying data type is a Set "points": [24, 30, 27] # underlying data type is a List "_version" : 3 } ``` La mutazione in entrata ha tre punti di interesse. Il nome, uno scalare, è stato modificato ma sono stati aggiunti due nuovi campi "interessi", un Set, "punti" e un Elenco. In questo scenario, verrà rilevato un conflitto a causa della mancata corrispondenza della versione. Automerge aderisce alle sue proprietà e rifiuta la modifica del nome data la sua natura scalare e l'add-on ai campi non in conflitto. In questo modo, l'elemento che viene salvato nel server viene visualizzato come segue. ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner"] # underlying data type is a Set "points": [24, 30, 27] # underlying data type is a List "_version" : 6 } ``` Con l'immagine aggiornata dell'elemento con la versione 6, ora supponiamo che una mutazione in entrata (con un'altra mancata corrispondenza della versione) cerchi di trasformare l'elemento nel seguente modo: ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "brunch"] # underlying data type is a Set "points": [30, 35] # underlying data type is a List "_version" : 5 } ``` Qui osserviamo che il campo in entrata per "interessi" ha un valore duplicato che esiste nel server e due nuovi valori. In questo caso, poiché il tipo di dati sottostante è un Set, Automerge combinerà i valori esistenti nel server con quelli nella richiesta in arrivo e rimuoverà eventuali duplicati. Allo stesso modo c'è un conflitto nel campo "punti" in cui c'è un valore duplicato e un nuovo valore. Ma poiché il tipo di dati sottostante qui è un elenco, Automerge aggiungerà semplicemente tutti i valori nella richiesta in entrata alla fine dei valori già esistenti nel server. L'immagine risultante unita memorizzata sul server apparirà come segue: ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set "points": [24, 30, 27, 30, 35] # underlying data type is a List "_version" : 7 } ``` Ora supponiamo che l'elemento memorizzato nel server appaia come segue, nella versione 8. ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set "points": [24, 30, 27, 30, 35] # underlying data type is a List "stats": { "ppg": "35.4", "apg": "6.3" } "_version" : 8 } ``` Ma supponiamo anche che una richiesta in entrata tenti di aggiornare l'elemento con la seguente immagine, ancora una volta con una mancata corrispondenza della versione: ``` { "id" : 1, "name" : "Nadia", "stats": { "ppg": "25.7", "rpg": "6.9" } "_version" : 3 } ``` Ora, in questo scenario, possiamo vedere che i campi che già esistono nel server sono mancanti (interessi, punti, jersey). Inoltre, il valore per "ppg" all'interno della mappa "statistiche" viene modificato, viene aggiunto un nuovo valore "rpg" e "apg" viene omesso. Automerge conserva i campi che sono stati omessi (nota: se i campi sono destinati a essere rimossi, allora la richiesta deve essere riprovata con la versione corrispondente), e quindi non andranno persi. Applicherà anche le stesse regole ai campi all'interno delle mappe e quindi la modifica a "ppg" verrà rifiutata mentre "apg" è conservato e "rpg", un nuovo campo, viene aggiunto. L'elemento risultante memorizzato nel server verrà ora visualizzato come: ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set "points": [24, 30, 27, 30, 35] # underlying data type is a List "stats": { "ppg": "35.4", "apg": "6.3", "rpg": "6.9" } "_version" : 9 } ``` ## Lambda Esistono diverse strategie di risoluzione Lambda tra cui scegliere: + `RESOLVE`: sostituisce l'articolo esistente con un nuovo articolo fornito nel payload di risposta. È possibile riprovare la stessa operazione solo su un singolo elemento alla volta. Attualmente supportato per DynamoDB `PutItem` e `UpdateItem`. + `REJECT`: rifiuta la mutazione e restituisce un errore con l'elemento esistente nella risposta GraphQL. Attualmente supportato per DynamoDB `PutItem`, `UpdateItem` e `DeleteItem`. + `REMOVE`: rimuove l'elemento esistente. Attualmente supportato per DynamoDB `DeleteItem`. **La richiesta di invocazione Lambda** Il AWS AppSync resolver DynamoDB richiama la funzione Lambda specificata in. `LambdaConflictHandlerArn` Utilizza lo stesso `service-role-arn` configurato per l'origine dati. Il payload dell'invocazione ha la seguente struttura: ``` { "newItem": { ... }, "existingItem": {... }, "arguments": { ... }, "resolver": { ... }, "identity": { ... } } ``` I campi sono definiti come segue: ** `newItem` ** L'elemento di anteprima, se la mutazione è riuscita. ** `existingItem` ** L'elemento attualmente risiede nella tabella DynamoDB. ** `arguments` ** Gli argomenti della mutazione GraphQL. ** `resolver` ** Informazioni sul resolver AWS AppSync . ** `identity` ** Informazioni sul chiamante. Questo campo è impostato su null, se l'accesso avviene con chiave API. Esempio di payload: ``` { "newItem": { "id": "1", "author": "Jeff", "title": "Foo Bar", "rating": 5, "comments": ["hello world"], }, "existingItem": { "id": "1", "author": "Foo", "rating": 5, "comments": ["old comment"] }, "arguments": { "id": "1", "author": "Jeff", "title": "Foo Bar", "comments": ["hello world"] }, "resolver": { "tableName": "post-table", "awsRegion": "us-west-2", "parentType": "Mutation", "field": "updatePost" }, "identity": { "accountId": "123456789012", "sourceIp": "x.x.x.x", "username": "AIDAAAAAAAAAAAAAAAAAA", "userArn": "arn:aws:iam::123456789012:user/appsync" } } ``` **La risposta all'invocazione Lambda** Per `PutItem` e risoluzione `UpdateItem` dei conflitti Rifiuto della mutazione (`RESOLVE`). La risposta deve essere nel seguente formato. ``` { "action": "RESOLVE", "item": { ... } } ``` Il campo `item` rappresenta un oggetto che verrà utilizzato per sostituire l'elemento esistente nell'origine dati sottostante. La chiave primaria e i metadati di sincronizzazione verranno ignorati se inclusi in `item`. Rifiuto della mutazione (`REJECT`). La risposta deve essere nel seguente formato. ``` { "action": "REJECT" } ``` Per la risoluzione dei conflitti `DeleteItem` `REMOVE` l'articolo. La risposta deve essere nel seguente formato. ``` { "action": "REMOVE" } ``` Rifiuto della mutazione (`REJECT`). La risposta deve essere nel seguente formato. ``` { "action": "REJECT" } ``` La funzione Lambda di esempio qui sotto controlla chi effettua la chiamata e il nome del resolver. Se è stato creato da`jeffTheAdmin`, `REMOVE` l'oggetto per il DeletePost resolver o il conflitto con un nuovo elemento per `RESOLVE` i resolver. Update/Put In caso contrario, la mutazione è `REJECT`. ``` exports.handler = async (event, context, callback) => { console.log("Event: "+ JSON.stringify(event)); // Business logic goes here. var response; if ( event.identity.user == "jeffTheAdmin" ) { let resolver = event.resolver.field; switch(resolver) { case "deletePost": response = { "action" : "REMOVE" } break; case "updatePost": case "createPost": response = { "action" : "RESOLVE", "item": event.newItem } break; default: response = { "action" : "REJECT" }; } } else { response = { "action" : "REJECT" }; } console.log("Response: "+ JSON.stringify(response)); return response; } ``` ## Errori Di seguito è riportato un elenco di possibili errori che possono verificarsi durante un processo di risoluzione dei conflitti: ** `ConflictUnhandled` ** Rilevamento dei conflitti individua una mancata corrispondenza della versione e il gestore dei conflitti rifiuta la mutazione. Esempio: risoluzione dei conflitti con un gestore di conflitti di Optimistic Concurrency. Oppure, il gestore di conflitti Lambda è stato restituito con `REJECT`. ** `ConflictError` ** Si verifica un errore interno quando si tenta di risolvere un conflitto. Esempio: il gestore di conflitti Lambda ha restituito una risposta non valida. In alternativa, non è possibile richiamare il gestore di conflitti Lambda perché la risorsa fornita `LambdaConflictHandlerArn` non viene trovata. ** `MaxConflicts` ** Sono stati raggiunti tentativi massimi per la risoluzione dei conflitti. Esempio: troppe richieste simultanee sullo stesso oggetto. Prima che il conflitto venga risolto, l'oggetto viene aggiornato a una nuova versione da un altro client. ** `BadRequest` ** Il client tenta di aggiornare i campi dei metadati (`_version`, `_ttl`, `_lastChangedAt`, `_deleted`). Esempio: il client tenta `_version` di aggiornare un oggetto con una mutazione di aggiornamento. ** `DeltaSyncWriteError` ** Impossibile scrivere il record di sincronizzazione delta. Esempio: la mutazione è riuscita, ma si è verificato un errore interno durante il tentativo di scrivere nella tabella di sincronizzazione delta. ** `InternalFailure` ** Si è verificato un errore interno. **`UnsupportedOperation`** Operazione non supportata ''. *X* Datasource Versioning supporta solo le seguenti operazioni (TransactGetItems,,, ScanPutItem, QueryBatchGetItem,,,, GetItem SyncDeleteItem). UpdateItem Esempio: utilizzo di determinate operazioni di transazione e batch con conflitto abilitato. detection/resolution Queste operazioni non sono attualmente supportate. ## CloudWatch Registri Se un' AWS AppSync API ha abilitato CloudWatch i registri con le impostazioni di registrazione impostate su Registri a livello di campo `enabled` e a livello di registro per i registri a livello di campo impostate su`ALL`, AWS AppSync invierà le informazioni di rilevamento e risoluzione dei conflitti al gruppo di log. Per informazioni sul formato dei messaggi di registro, consulta la [documentazione relativa al rilevamento conflitti e alla registrazione di sincronizzazione](monitoring.md#aws-appsync-monitoring-conflict-detection-and-sync-logging). # Utilizzo delle operazioni di sincronizzazione di DynamoDB su sorgenti dati con versione in AWS AppSync Le fonti di dati con versione supportano `Sync` operazioni che consentono di recuperare tutti i risultati da una tabella DynamoDB e quindi ricevere solo i dati modificati dall'ultima query (gli aggiornamenti delta). Quando AWS AppSync riceve una richiesta di `Sync` operazione, utilizza i campi specificati nella richiesta per determinare se è necessario accedere alla tabella *Base o alla* tabella *Delta*. + Se il `lastSync` campo non è specificato, viene eseguita una `Scan` nella tabella *Base*. + Se il campo `lastSync` è specificato, ma il valore è prima del `current moment - DeltaSyncTTL`, viene eseguita una `Scan` sulla tabella di *base*. + Se il campo `lastSync` è specificato e il valore è attivo o dopo `current moment - DeltaSyncTTL`, viene eseguita una `Query` sulla tabella *Delta*. AWS AppSync restituisce il `startedAt` campo al modello di mappatura delle risposte per tutte le `Sync` operazioni. Il campo `startedAt` è il momento, in millisecondi dall'epoca, in cui è iniziata l'operazione `Sync` che è possibile memorizzare localmente e utilizzare in un'altra richiesta. Se un token di paginazione è stato incluso nella richiesta, questo valore sarà lo stesso di quello restituito dalla richiesta per la prima pagina di risultati. Per informazioni sul formato per i modelli di mappatura `Sync`, consulta il [riferimento del modello di mappatura](aws-appsync-resolver-mapping-template-reference-dynamodb-sync.md).