DynoTable

Não é possível realizar operações em uma tabela inexistente (DynamoDB Local)

TL;DR - Este é o texto do DynamoDB Local para ResourceNotFoundException, e a armadilha é que "inexistente" tem como escopo o arquivo de banco de dados que esta instância abriu para sua chave de acesso + região atual. Sem -sharedDb, o Local mantém uma tabela separada definida por combinação de credenciais/region - para que a tabela que você criou com a CLI possa ficar invisível para seu aplicativo. Execute Local com -sharedDb (ou fixe credenciais fictícias + região idênticas em todos os lugares) e lembre-se de que -inMemory começa vazio a cada reinicialização.

O que significa

ResourceNotFoundException: Cannot do operations on a non-existent table

Sua solicitação chegou a um DynamoDB Local em execução, que procurou a tabela e não a encontrou — no banco de dados que está usando para a identidade da sua solicitação. O AWS real expressa a mesma falha de maneira diferente (Requested resource not found), então esta mensagem exata é uma forte dica de que você está falando com um emulador.

Por que isso acontece

  • Credencial/region split-brain (o clássico). Sem -sharedDb, o DynamoDB Local nomeia seu arquivo de banco de dados de acordo com o ID da chave de acesso e a região de cada solicitação. Sua CLI (--profile com chave local, região us-east-1) e seu aplicativo (chave fake, região local) portanto, consulte dois conjuntos de tabelas diferentes — cada um criou a tabela "para si".
  • -inMemory + reinicialização — o modo na memória não mantém nada no disco; cada reinicialização é um banco de dados em branco.
  • Um recipiente novo sem volume — docker run amazon/dynamodb-local começa vazio; as tabelas do contêiner anterior desaparecerão, a menos que você monte o armazenamento -dbPath.
  • A tabela realmente não foi criada — os scripts de configuração não foram executados ou a criaram em uma porta/instance diferente.
  • Mesmo código apontado para AWS real vs Local — a tabela existe na nuvem, mas não no emulador (ou vice-versa).

Como corrigir

  1. Veja o que ESTA identidade vê — liste tabelas com exatamente as credenciais/region/endpoint que seu aplicativo usa:

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

    Se a tabela estiver faltando aqui, mas existir "em algum lugar", é o escopo.

  2. Execute o Local com -sharedDb para que todo cliente compartilhe um único banco de dados, independentemente das credenciais/região:

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

  3. Ou fixe uma identidade em todos os lugares — o mesmo accessKeyId, secretAccessKey e region fictício no perfil CLI, configuração do cliente SDK e configuração de teste.

  4. Persistir nas reinicializações — elimine o -inMemory, defina o -dbPath e (no Docker) monte-o como um volume.

  5. Crie tabelas na configuração — para testes, crie a tabela (e espere por ela) no bootstrap da suíte para que uma nova instância nunca seja uma surpresa.

DynoTable + Local

O problema do escopo é muito mais fácil de ver do que deduzir. Instalar DynoTable, adicione um perfil local (Configurações → Perfis → Adicionar perfil) com endpoint http://localhost:8000 e a mesma chave de acesso + região que sua CLI usa, então compare a lista de tabelas da barra lateral com aws dynamodb list-tables --endpoint-url http://localhost:8000. Credenciais incompatíveis dividem tabelas em tabelas separadas Arquivos myaccesskeyid_region.db (Executando DynamoDB Local). Após a reinicialização do -inMemory, use o conversor DynamoDB JSON para recarregar equipamentos.

FAQ

Por que o DynamoDB Local diz que a tabela não existe quando acabei de criá-la? Sem o -sharedDb, o DynamoDB Local mantém um arquivo de banco de dados separado por ID de chave de acesso e região, para que a tabela que você criou com a CLI possa ficar invisível para seu aplicativo se suas credenciais ou região forem diferentes. Execute Local com -sharedDb ou fixe credenciais e regiões fictícias idênticas em qualquer lugar.

Por que minhas tabelas locais DynamoDB desapareceram após uma reinicialização? No modo -inMemory nada é mantido no disco, então cada reinicialização é um banco de dados em branco. Um contêiner Docker novo sem um volume montado também começa vazio. Elimine -inMemory, configure -dbPath e monte-o como um volume para persistir tabelas.

Erros relacionados

Fontes

Trabalhe com o DynamoDB sem o Console

Um cliente desktop rápido para DynamoDB que roda o SQL de verdade que o DynamoDB não consegue — JOINs, GROUP BY, agregações — com edição visual e um agente de IA com suas próprias chaves do Bedrock.

BaixarVer preços

Teste grátis de 30 dias, sem cartão de crédito — depois o plano Grátis sem limite de tempo.