Não quer configurar isso manualmente? Cole o link desta página em uma sessão do Devin e peça para ele configurar tudo para você. 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. Vá para [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) e clique em **avançado** 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. ```txt Improve the db-migration playbook theme={null} Our !db-migration playbook works for simple table changes but fails when sessions hit foreign key constraints. Sessions 1 and 2 succeeded on standalone tables, but sessions 3 and 4 crashed on FK errors. Analyze all 4. Figure out what the successful sessions did differently (they hit standalone tables with no incoming FKs). Then update the playbook to: 1. Query information_schema for FK dependencies before any DROP or ALTER 2. Generate ALTER TABLE ... DROP CONSTRAINT statements when FKs exist 3. Add a rollback step that re-creates dropped constraints if the migration fails partway through ``` 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 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." Você não precisa sair da sessão atual do 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: ```txt Test the updated playbook theme={null} Use the !db-migration playbook to drop the legacy_account_id column from the users table. This column is referenced by orders.account_id and invoices.billing_account_id — the playbook should handle the FK dependencies automatically. ``` 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.

{title}