Skip to main content
1

Individua il pattern tra le sessioni

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.
2

Apri la scheda Improve Playbook con i link alle sessioni

Vai su app.devin.ai 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.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
3

Rivedi il diff del playbook

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.”
4

Verifica la correzione su una nuova migrazione

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: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.