Scrittura condizionale DynamoDB con la AWS CLI

Una scrittura condizionale collega una --condition-expression a put-item, update-item o delete-item: DynamoDB la valuta rispetto all'Item corrente e applica la scrittura solo se è vera — in modo atomico, senza race di lettura-modifica-scrittura. È la primitiva di locking ottimistico di DynamoDB. Questo esempio protegge un aggiornamento con un controllo di versione.

Code

aws dynamodb update-item \
  --table-name 'Music' \
  --key '{"Artist":{"S":"Arturo Sandoval"},"SongTitle":{"S":"Cubano Chant"}}' \
  --update-expression 'SET #upd0 = :updValue0, #version = :newVersion' \
  --condition-expression 'attribute_exists(#cond0) AND #version = :expectedVersion' \
  --expression-attribute-names '{"#upd0":"Genre","#version":"Version","#cond0":"Artist"}' \
  --expression-attribute-values '{":updValue0":{"S":"Latin Jazz"},":expectedVersion":{"N":"7"},":newVersion":{"N":"8"}}'

In caso di successo il comando non stampa nulla ed esce con 0. Se un altro writer è arrivato prima, la condizione fallisce:

An error occurred (ConditionalCheckFailedException) when calling the UpdateItem operation:
The conditional request failed

Spiegazione

--condition-expression — verificata rispetto all'Item memorizzato in modo atomico con la scrittura. Funzioni disponibili: attribute_exists, attribute_not_exists, attribute_type, contains, begins_with, size, più i comparatori (=, <>, <, >, <=, >=, BETWEEN, IN) e AND/OR/NOT.
I due idiomi principali:
- attribute_exists(#key) su un update = "solo aggiornamento, mai creazione". Senza di essa, update-item su una chiave mancante crea silenziosamente l'Item (il bug dell'upsert accidentale).
- attribute_not_exists(#key) su un put = "solo creazione, mai sovrascrittura" — mostrato nella pagina PutItem.
Locking ottimistico — leggi l'Item (versione 7), poi scrivi con #version = :expectedVersion incrementando a 8. Due writer concorrenti non possono vincere entrambi; il perdente esce con codice diverso da zero e ConditionalCheckFailedException, rilegge e riprova sulla nuova versione.
--return-values-on-condition-check-failure ALL_OLD — chiede a DynamoDB di allegare l'Item corrente all'errore (valori validi ALL_OLD | NONE; nessuna capacità di lettura consumata). Gli SDK espongono quell'Item sull'eccezione; l'output di errore predefinito della CLI stampa solo il messaggio, quindi gli script di solito rileggono con get-item dopo un errore.
Una scrittura condizionale fallita fattura comunque il tentativo di scrittura — non usare le condizioni come una sonda di esistenza gratuita.

Fallo visivamente

Le espressioni di condizione sono esattamente ciò che costruisce il DynamoDB Expression Builder — scegli la funzione, ottieni l'espressione + le mappe di nomi/valori come comando CLI pronto da eseguire.

Per modificare gli Item con espressioni generate e verificabili invece di segnaposto tra virgolette nella shell — scarica DynoTable.

Esempi correlati

Scrittura condizionale DynamoDB in Node.js — lo stesso lock ottimistico con AWS SDK v3.
Scrittura condizionale DynamoDB in Python — lo stesso lock ottimistico con boto3.
DynamoDB PutItem con la AWS CLI — il put di sola creazione con attribute_not_exists.
Espressioni di condizione DynamoDB — ogni funzione, con esempi di pattern.
Capire ReturnValues — cosa ti offre ciascuna opzione di ritorno.
DynamoDB ConditionalCheckFailedException — quando il controllo fallito è previsto e come gestirlo a basso costo.

References

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.