DynoTable

No se pueden realizar operaciones en una tabla inexistente (DynamoDB Local)

TL;DR: esta es la redacción local de DynamoDB ResourceNotFoundException, y la trampa es que "inexistente" tiene como alcance el archivo de base de datos que esta instancia abrió para su clave de acceso actual + región. Sin -sharedDb, Local mantiene una tabla separada establecida por combinación de credenciales/región, por lo que la tabla que creó con CLI puede ser invisible para su aplicación. Ejecute Local con -sharedDb (o fije credenciales ficticias idénticas + región en todas partes) y recuerde que -inMemory comienza vacío en cada reinicio.

Qué significa

ResourceNotFoundException: Cannot do operations on a non-existent table

Tu petición llegó a un DynamoDB Local en ejecución, que buscó la tabla y no la encontró — en la base de datos que está usando para la identidad de tu petición. AWS real redacta el mismo fallo de otra forma (Requested resource not found), así que este mensaje exacto es una pista fuerte de que estás hablando con un emulador.

Por qué ocurre

  • Cerebro dividido de credencial/región (el clásico). Sin -sharedDb, DynamoDB Local nombra su fichero de base de datos según el access key ID y la región de cada petición. Tu CLI (--profile con clave local, región us-east-1) y tu aplicación (clave fake, región local) ven por tanto dos conjuntos de tablas distintos — cada uno creó la tabla "para sí mismo".
  • -inMemory + un reinicio — el modo en memoria no guarda nada en disco; cada reinicio es una base de datos en blanco.
  • Un contenedor nuevo sin volumen — docker run amazon/dynamodb-local arranca vacío; las tablas del contenedor anterior desaparecen salvo que montaras almacenamiento con -dbPath.
  • La tabla realmente no se creó — los scripts de configuración no se ejecutaron, o la crearon contra otro puerto/instancia.
  • El mismo código apuntando a AWS real vs Local — la tabla existe en la nube pero no en el emulador (o viceversa).

Cómo solucionarlo

  1. Ve lo que ESTA identidad ve — lista las tablas exactamente con las credenciales/región/endpoint que usa tu aplicación:

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

    Si la tabla falta aquí pero existe "en algún sitio", es el acotamiento.

  2. Ejecuta Local con -sharedDb para que cada cliente comparta una base de datos independientemente de las credenciales/región:

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

  3. O fija una identidad en todas partes — el mismo accessKeyId, secretAccessKey y region dummy en el perfil de la CLI, la configuración del cliente del SDK y la configuración de tests.

  4. Persiste entre reinicios — quita -inMemory, define -dbPath y (en Docker) móntalo como volumen.

  5. Crea las tablas en la configuración — para los tests, crea la tabla (y espera a ella) en el bootstrap de la suite para que una instancia nueva nunca sea una sorpresa.

DynoTable + Local

El problema de acotamiento es mucho más fácil de ver que de deducir. Instala DynoTable, añade un perfil Local (Settings → Profiles → Add Profile) con endpoint http://localhost:8000 y la misma clave de acceso + región que usa tu CLI, y luego compara la lista de tablas de la barra lateral con aws dynamodb list-tables --endpoint-url http://localhost:8000. Unas credenciales que no coinciden reparten las tablas entre ficheros myaccesskeyid_region.db distintos (Ejecutar DynamoDB Local). Tras un reinicio con -inMemory, usa el conversor de DynamoDB JSON para recargar los fixtures.

FAQ

¿Por qué DynamoDB Local dice que la tabla no existe cuando acabo de crearla? Sin -sharedDb, DynamoDB Local mantiene un fichero de base de datos separado por access key ID y región, así que la tabla que creaste con la CLI puede ser invisible para tu aplicación si sus credenciales o su región difieren. Ejecuta Local con -sharedDb o fija credenciales dummy y región idénticas en todas partes.

¿Por qué desaparecieron mis tablas de DynamoDB Local tras un reinicio? En modo -inMemory no se guarda nada en disco, así que cada reinicio es una base de datos en blanco. Un contenedor de Docker nuevo sin un volumen montado también arranca vacío. Quita -inMemory, define -dbPath y móntalo como volumen para persistir las tablas.

Errores relacionados

Fuentes

Trabaja con DynamoDB sin la Consola

Un cliente de escritorio rápido para DynamoDB que ejecuta el SQL real que DynamoDB no puede — JOINs, GROUP BY, agregaciones — con edición visual y un agente de IA con tus propias claves de Bedrock.

DescargarVer precios

Prueba gratuita de 30 días, sin tarjeta — después, el plan Free sin límite de tiempo.