Skip to main content

Corrigir um Playbook de Migração de Banco de Dados Instável

Seu playbook de migração de banco de dados funciona em esquemas simples, mas falha em chaves estrangeiras. Forneça quatro links de sessão ao Advanced Devin e deixe que ele corrija as lacunas.
AuthorCognition
CategoryOtimização do Devin
FeaturesAvançado, Playbooks
1

Identifique o padrão entre sessões

Sua equipe vem usando o playbook !db-migration há algumas semanas. Ele lidou com renomear colunas e adicionar índices sem problemas — mas as duas últimas sessões travaram no meio da migração quando tentaram remover uma coluna referenciada por outras tabelas.Abra cada sessão e observe o ponto de falha. Neste caso, as sessões 3 e 4 apresentaram erro na mesma etapa:
ERROR: cannot drop column "account_id" because other objects depend on it
DETAIL: constraint fk_orders_account_id on table orders depends on column account_id
HINT: Use DROP ... CASCADE to drop dependent objects too.
Agora você tem um sinal claro: o playbook não tem uma etapa para verificar dependências de chave estrangeira antes de operações destrutivas. Duas sessões tiveram sucesso porque atuaram em tabelas independentes; duas falharam porque não atuaram.
2

Abra a aba Improve Playbook com links de sessão

Vá para app.devin.ai e clique em Advanced abaixo da caixa de entrada. Selecione a aba Improve Playbook.Escolha !db-migration no menu suspenso de playbooks e então selecione todas as quatro sessões no session multi-dropdown — tanto as bem-sucedidas quanto as que falharam. Incluir sessões bem-sucedidas permite que o Devin veja o que o playbook faz bem, não apenas onde ele quebra.O que torna esse prompt eficaz:
  • Nomeia exatamente a falha — “foreign key constraints” em vez de “às vezes falha”
  • Contrasta sucessos e falhas — o Devin pode comparar as transcrições das sessões para ver onde elas divergem
  • Lista correções concretas, deixando espaço para o Devin apontar problemas que você não percebeu
3

Revise o diff do playbook

O Devin lê as transcrições das quatro sessões, identifica onde as falhas divergiram dos sucessos e propõe edições específicas. A saída parece um changelog para o seu playbook:
## Analysis

Sessions 1-2 succeeded because they only modified tables with no
incoming foreign keys. Sessions 3-4 failed at step 4 ("Drop the
old column") because the orders and invoices tables had FK
references to the target column.

## Changes to !db-migration

Added step 3a: "Before any DROP or ALTER that removes a column,
  query information_schema.key_column_usage to list dependent FKs.
  If any exist, generate ALTER TABLE ... DROP CONSTRAINT statements
  and execute them first. Save the original constraint DDL for
  rollback."

Added step 7: "Rollback procedure — if any step after FK removal
  fails, re-create the dropped constraints using the saved DDL
  from step 3a."

Updated Advice section: "Always run the migration against a staging
  database first. FK chains can be deeper than expected — a column
  in table A may be referenced by B, which is referenced by C.
  Query recursively."
O playbook é salvo automaticamente. Se algo estiver errado, responda na mesma sessão — por exemplo: “Também adicione uma etapa para notificar o canal #database no Slack antes de executar migrações destrutivas.”
4

Verifique a correção em uma nova migração

Você não precisa sair da sessão atual do Advanced Devin. Depois que a atualização do playbook for salva, use a mesma sessão para iniciar uma sessão padrão do Devin que teste o playbook atualizado no exato cenário que falhou antes:Se essa sessão tiver sucesso, a correção funciona. Se encontrar um novo edge case (por exemplo, referências de chave estrangeira circulares), envie essa sessão de volta para a aba Improve Playbook para outra rodada.