Vous ne voulez pas configurer cela manuellement ? Collez un lien vers cette page dans une session Devin et demandez-lui de tout configurer pour vous. 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. Allez sur [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) et cliquez sur **avancé** 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. ```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 ``` Ce qui rend ce prompt efficace : * **Nomme l’échec exact** — « contraintes de clé étrangère » 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 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. » Vous n’avez pas besoin de quitter votre session 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 : ```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 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.

{title}