¿No quieres configurar esto manualmente? Pega un enlace a esta página en una sesión de Devin y pídele que lo configure todo por ti. Tu equipo ha estado usando el playbook `!db-migration` durante unas semanas. Ha manejado el cambio de nombre de columnas y la adición de índices sin problema, pero las dos últimas sesiones se bloquearon a mitad de la migración cuando intentaron eliminar una columna referenciada por otras tablas. Abre cada sesión y revisa el punto de fallo. En este caso, las sesiones 3 y 4 dieron error en el mismo paso: ``` 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. ``` Ahora tienes una señal clara: el playbook no tiene un paso para comprobar las dependencias de claves foráneas antes de operaciones destructivas. Dos sesiones tuvieron éxito porque afectaron a tablas independientes; dos fallaron porque no lo hicieron. Ve a [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) y haz clic en **Advanced** debajo del cuadro de entrada. Selecciona la pestaña **Improve Playbook**. Elige `!db-migration` en el desplegable de playbooks y luego selecciona las cuatro sesiones en el **session multi-dropdown**, tanto las exitosas como las fallidas. Incluir sesiones exitosas permite que Devin vea en qué funciona bien el playbook, no solo dónde se rompe. ```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 ``` Qué hace que este prompt sea eficaz: * **Nombra el fallo exacto** — "foreign key constraints" en lugar de "a veces falla" * **Contrasta éxitos y fallos** — Devin puede comparar las transcripciones de las sesiones para ver dónde divergen * **Enumera correcciones concretas** mientras deja espacio para que Devin saque a la luz problemas que pasaste por alto Devin lee las transcripciones de las cuatro sesiones, identifica dónde los fallos divergen de los éxitos y propone ediciones específicas. La salida se ve como un changelog de tu 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." ``` El playbook se guarda automáticamente. Si algo no encaja, responde en la misma sesión; por ejemplo: "Also add a step to notify the #database Slack channel before running destructive migrations." No necesitas salir de tu sesión actual de Devin. Una vez que se guarde la actualización del playbook, usa la misma sesión para iniciar una sesión estándar de Devin que pruebe el playbook actualizado contra el mismo escenario que falló 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. ``` Si esta sesión tiene éxito, la corrección funciona. Si encuentra un nuevo caso límite (por ejemplo, referencias de FK circulares), vuelve a enviar esa sesión a la pestaña Improve Playbook para otra iteración.

{title}