Skip to main content

Corriger un playbook de migration de base de données peu fiable

Votre playbook de db-migration fonctionne sur des schémas simples mais échoue dès qu’il y a des clés étrangères. Transmettez quatre liens de session à Advanced Devin et laissez-le combler les lacunes.
AuthorCognition
CategoryOptimisation de Devin
FeaturesAvancé, Playbooks
1

Repérer le motif à travers les sessions

Votre équipe utilise le playbook !db-migration depuis quelques semaines. Il a géré le renommage de colonnes et l’ajout d’index sans problème — mais les deux dernières sessions ont planté en milieu de migration lorsqu’elles ont essayé de supprimer une colonne référencée par d’autres tables.Ouvrez chaque session et regardez le point d’échec. Dans ce cas, les sessions 3 et 4 ont toutes deux échoué à la même étape :
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.
Vous disposez maintenant d’un signal clair : le playbook n’a aucune étape pour vérifier les dépendances de clés étrangères avant les opérations destructrices. Deux sessions ont réussi parce qu’elles touchaient des tables autonomes ; deux ont échoué parce que ce n’était pas le cas.
2

Ouvrir l’onglet Improve Playbook avec les liens de session

Allez sur app.devin.ai et cliquez sur Advanced sous la zone de saisie. Sélectionnez l’onglet Improve Playbook.Choisissez !db-migration dans la liste déroulante des playbooks, puis sélectionnez les quatre sessions dans le menu déroulant multi-sélection des sessions — à la fois les réussites et les échecs. Inclure des sessions réussies permet à Devin de voir ce que le playbook fait bien, pas seulement là où il échoue.Ce qui rend ce prompt efficace :
  • Nomme l’échec exact — « foreign key constraints » au lieu de « il échoue parfois »
  • Oppose réussites et échecs — Devin peut comparer les transcriptions de session pour voir où elles divergent
  • Liste des correctifs concrets tout en laissant à Devin la possibilité de faire remonter des problèmes que vous auriez manqués
3

Examiner le diff du playbook

Devin lit les transcriptions des quatre sessions, identifie précisément où les échecs ont divergé des réussites et propose des modifications ciblées. Le résultat ressemble à un changelog pour votre 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."
Le playbook est enregistré automatiquement. Si quelque chose ne va pas, répondez dans la même session — par exemple : « Ajoute aussi une étape pour notifier le canal Slack #database avant d’exécuter des migrations destructrices. »
4

Vérifier la correction sur une nouvelle migration

Vous n’avez pas besoin de quitter votre session Advanced Devin actuelle. Une fois la mise à jour du playbook enregistrée, utilisez la même session pour lancer une session Devin standard qui teste le playbook mis à jour sur le scénario exact qui avait échoué auparavant :Si cette session réussit, la correction fonctionne. Si elle rencontre un nouveau cas limite (par exemple, des références de clés étrangères circulaires), renvoyez cette session dans l’onglet Improve Playbook pour un nouveau cycle.