DynoTable

Non è possibile eseguire operazioni su una tabella inesistente (DynamoDB Locale)

TL;DR — Questa è la formulazione di DynamoDB Local di ResourceNotFoundException e la trappola è che "inesistente" ha come ambito il file di database aperto da questa istanza per la tua chiave di accesso corrente + regione. Senza -sharedDb, Local mantiene una tabella separata impostata per combinazione credenziali/regione, in modo che la tabella creata con la CLI possa essere invisibile alla tua app. Esegui Locale con -sharedDb (o aggiungi credenziali fittizie identiche + regione ovunque) e ricorda che -inMemory inizia vuoto ad ogni riavvio.

Cosa significa

ResourceNotFoundException: Cannot do operations on a non-existent table

La tua richiesta ha raggiunto un DynamoDB Local in esecuzione, che ha cercato la tabella e non l'ha trovata — nel database che sta utilizzando per l'identità della tua richiesta. Real AWS esprime lo stesso errore in modo diverso ("Risorsa richiesta non trovata"), quindi questo messaggio esatto è un forte indizio che stai parlando con un emulatore.

Perché succede

  • Credenziale/regione split-brain (il classico). Senza -sharedDb, DynamoDB Local nomina il suo file di database dopo l'ID della chiave di accesso e la regione di ciascuna richiesta. La tua CLI (--profile con chiave local, regione us-east-1) e la tua app (chiave fake, regione local) vedono quindi due diversi set di tabelle: ciascuno ha creato la tabella "per se stesso".
  • -inMemory + un riavvio — la modalità in memoria non mantiene nulla sul disco; ogni riavvio è un database vuoto.
  • Un nuovo contenitore senza volume — docker run amazon/dynamodb-local inizia vuoto; le tabelle del contenitore precedente scompaiono a meno che non sia stata montata la memoria -dbPath.
  • La tabella non è stata realmente creata: gli script di installazione non sono stati eseguiti o sono stati creati su una porta/istanza diversa.
  • Stesso codice puntato su real AWS vs Local: la tabella esiste nel cloud ma non nell'emulatore (o viceversa).

Come risolverlo

  1. Guarda cosa vede QUESTA identità: elenca le tabelle con esattamente le credenziali/regione/endpoint utilizzati dalla tua app:

    AWS_ACCESS_KEY_ID=local AWS_SECRET_ACCESS_KEY=local \
aws dynamodb list-tables --endpoint-url http://localhost:8000 --region us-east-1

  2. Esegui Local con -sharedDb in modo che ogni client condivida un database indipendentemente dalle credenziali/regione:

    java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb
# docker: docker run -p 8000:8000 amazon/dynamodb-local -jar DynamoDBLocal.jar -sharedDb

  3. Oppure aggiungi un'identità ovunque: gli stessi accessKeyId, secretAccessKey e region fittizi nel profilo CLI, nella configurazione del client SDK e nella configurazione del test.

  4. Perseverare tra i riavvii: rilasciare -inMemory, impostare -dbPath e (in Docker) montarlo come volume.

  5. Crea tabelle nella configurazione: per i test, crea la tabella (e attendila) nel bootstrap della suite in modo che una nuova istanza non sia mai una sorpresa.

DynoTable + Local

Il problema dell'ambito è molto più facile da vedere che da dedurre. Installa DynoTable, aggiungere un profilo locale (Impostazioni → Profili → Aggiungi profilo) con endpoint http://localhost:8000 e la stessa chiave di accesso + regione utilizzata dalla CLI, quindi confrontare l'elenco delle tabelle della barra laterale con aws dynamodb list-tables --endpoint-url http://localhost:8000. Le credenziali non corrispondenti dividono le tabelle in tabelle separate File myaccesskeyid_region.db (In esecuzione DynamoDB Locale). Dopo il riavvio di -inMemory, utilizza il convertitore DynamoDB JSON per ricaricare i dispositivi.

FAQ

Perché DynamoDB Local dice che la tabella non esiste quando l'ho appena creata? Senza -sharedDb, DynamoDB Local mantiene un file di database separato per ID chiave di accesso e regione, quindi la tabella creata con la CLI può essere invisibile alla tua app se le credenziali o la regione differiscono. Esegui Local con -sharedDb o aggiungi credenziali fittizie e regione identiche ovunque.

Perché le mie DynamoDB tabelle locali sono scomparse dopo il riavvio? Nella modalità -inMemory nulla viene mantenuto sul disco, quindi ogni riavvio è un database vuoto. Anche un nuovo contenitore Docker senza volume montato inizia vuoto. Rilascia -inMemory, imposta -dbPath e montalo come volume per rendere persistenti le tabelle.

Errori correlati

Fonti

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.

ScaricaVedi i prezzi

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