I livelli di nidificazione hanno superato i limiti supportati

TL;DR — DynamoDB consente di nidificare tipi di documenti (mappa M e lista L) l'uno dentro l'altro fino a 32 livelli di profondità. Una struttura che va più in profondità viene rifiutata con una ValidationException. Appiattisci il modello dati, dividi il ramo profondo in un elemento separato o archivia il sottoalbero over-deep come un'unica stringa serializzata.

Cosa significa

ValidationException: 1 validation error detected: Nesting Levels have exceeded supported limits

# what the engine actually returns, reproduced against DynamoDB Local:
ValidationException: 1 validation error detected: Nesting Levels have exceeded supported limits: Attributes in the item have nested levels beyond supported limit

(Questa è la dicitura AWS documenti per questo errore di convalida; la frase esatta può variare leggermente in base all'operazione.) Un valore di attributo può essere uno scalare o una mappa/lista che contiene più valori — e DynamoDB limiti che si annidano a 32 livelli. Lo stesso limite si applica alle espressioni: la profondità massima per un percorso di documento è 32, quindi non è possibile fare riferimento nemmeno a una profondità maggiore. Il limite conta la profondità delle mappe e degli elenchi, non il numero di attributi. Al superamento si verifica una ValidationException HTTP 400, rilevata al momento della convalida e non riprovabile finché il documento non viene ristrutturato.

Perché succede

  • Dati profondamente ricorsivi: strutture ad albero/grafico (organigrammi, thread di commenti, categorie nidificate) serializzate come mappe all'interno di mappe oltre 32 livelli.
  • Un serializzatore generico: codice che effettua il marshalling di JSON nidificati arbitrari direttamente in DynamoDB tipi di documenti senza una protezione di profondità.
  • Autonidificazione accidentale: un bug che avvolge ripetutamente un oggetto al suo interno.
  • Documenti migrati da un database di documenti la cui nidificazione non è mai stata delimitata.

Come risolverlo

  1. Appiattire il modello: inserire sottostrutture profonde in attributi di livello superiore o in un layout a chiave composita anziché in mappe sempre più profonde.
  2. Diviso in più elementi: modella il ramo profondo come elementi separati sotto la stessa chiave di partizione (il modello di adiacenza a tabella singola).
  3. Serializza il sottoalbero profondo: memorizza la porzione troppo profonda come un attributo stringa JSON (opaco a DynamoDB, quindi la sua profondità interna non conta più) se non è necessario eseguire query al suo interno.
  4. Aggiungi una protezione di profondità nel livello di smistamento in modo che i documenti non possano superare silenziosamente il limite.
  5. Misura la profondità prima della scrittura. Percorri la struttura del documento nel serializzatore e rifiuta qualsiasi cosa superiore a 30 livelli: lascia spazio per un ulteriore percorso di aggiornamento.

Misura in DynoTable

Ispeziona gli attributi nidificati in DynoTable prima di scriverli: apri un elemento con ⌘K ed espandi i campi mappa/elenco nel visualizzatore JSON per vedere quanto è profonda la struttura. La gestione temporanea (⌘S) consente di visualizzare in anteprima un inserimento/aggiornamento e di rilevare errori di profondità prima del commit.

Utilizza il calcolatore della dimensione dell'elemento insieme ai controlli approfonditi: anche l'annidamento profondo spesso spinge gli elementi verso il limite di 400 KB. Cambia profilo con ⌘P durante il test contro Locale vs AWS. Configurazione: Connetti a AWS, Installa.

Fonti

Errori correlati

Riferimenti

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

Lavora con DynamoDB senza la Console

Un client desktop veloce per DynamoDB che esegue il vero SQL che DynamoDB non può — JOINs, GROUP BY, aggregazioni — con modifica visuale e un agente AI sulle tue chiavi Bedrock.

Prova gratuita di 30 giorni, senza carta di credito — poi il piano Free senza limiti di tempo.