Non vuoi configurare tutto manualmente? Incolla un collegamento a questa pagina in una sessione Devin e chiedi a Devin di configurare tutto per te. Il tuo team utilizza il playbook `!db-migration` da alcune settimane. Ha gestito senza problemi la rinomina delle colonne e l'aggiunta di indici, ma le ultime due sessioni sono andate in crash a metà migrazione quando hanno provato a eliminare una colonna referenziata da altre tabelle. Apri ogni sessione e osserva il punto di errore. In questo caso, le sessioni 3 e 4 hanno entrambe generato errore allo stesso step: ``` 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. ``` Ora hai un segnale chiaro: il playbook non prevede uno step per controllare le dipendenze delle chiavi esterne prima delle operazioni distruttive. Due sessioni sono riuscite perché toccavano tabelle isolate; due sono fallite perché non lo facevano. Vai su [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) e fai clic su **Advanced** sotto il campo di input. Seleziona la scheda **Improve Playbook**. Seleziona `!db-migration` dal menu a tendina dei playbook, quindi seleziona tutte e quattro le sessioni dal **session multi-dropdown** — sia quelle riuscite sia quelle fallite. Includere le sessioni riuscite permette a Devin di vedere in cosa il playbook è efficace, non solo dove si 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 ``` Cosa rende efficace questo prompt: * **Nomina esattamente il problema** — "vincoli di chiave esterna" invece di "a volte fallisce" * **Mette a confronto successi e fallimenti** — Devin può confrontare i transcript delle sessioni per vedere dove divergono * **Elenca correzioni concrete**, lasciando comunque spazio a Devin per far emergere problemi che potresti aver mancato Devin legge i transcript di tutte e quattro le sessioni, individua dove i fallimenti sono divergiti dai successi e propone modifiche mirate. L'output sembra un changelog per il tuo 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." ``` Il playbook viene salvato automaticamente. Se qualcosa non va, rispondi nella stessa sessione — ad esempio: "Aggiungi anche uno step per notificare il canale Slack #database prima di eseguire migrazioni distruttive." Non devi lasciare la tua sessione Devin attuale. Dopo che l'aggiornamento del playbook è stato salvato, usa la stessa sessione per avviare una sessione Devin standard che testi il playbook aggiornato contro lo stesso scenario che era fallito in precedenza: ```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 questa sessione riesce, la correzione funziona. Se incontra un nuovo edge case (ad esempio, riferimenti FK circolari), reinserisci quella sessione nella scheda Improve Playbook per un altro giro.

{title}