Skip to main content

Correggere un playbook di migrazione DB instabile

Il tuo playbook di migrazione del database funziona con schemi semplici ma va in errore con le chiavi esterne. Fornisci quattro link di sessione ad Advanced Devin e lascialo colmare le lacune.
AuthorCognition
CategoryOttimizzazione di Devin
FeaturesAvanzato, Playbook
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 attuale sessione Advanced Devin. 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.