Möchtest du das nicht manuell einrichten? Füge einen Link zu dieser Seite in eine Devin-Session ein und bitte Devin, alles für dich einzurichten. Dein Team verwendet das `!db-migration` Playbook seit ein paar Wochen. Es hat das Umbenennen von Spalten und das Hinzufügen von Indizes problemlos gehandhabt – aber die letzten beiden Sessions sind mitten in der Migration abgestürzt, als versucht wurde, eine Spalte zu droppen, auf die andere Tabellen verweisen. Öffne jede Session und sieh dir die Fehlerstelle an. In diesem Fall sind die Sessions 3 und 4 beide an demselben Schritt fehlgeschlagen: ``` 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. ``` Du hast jetzt ein klares Signal: Das Playbook hat keinen Schritt, um Fremdschlüsselabhängigkeiten vor destruktiven Operationen zu prüfen. Zwei Sessions waren erfolgreich, weil sie nur eigenständige Tabellen bearbeitet haben; zwei sind fehlgeschlagen, weil sie das nicht taten. Gehe zu [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) und klicke auf **Advanced** unter dem Eingabefeld. Wähle den Tab **Improve Playbook**. Wähle `!db-migration` aus dem Playbook-Dropdown und markiere dann alle vier Sessions im **Session-Multi-Dropdown** – sowohl die erfolgreichen als auch die fehlgeschlagenen. Erfolgreiche Sessions einzubeziehen ermöglicht es Devin zu sehen, was das Playbook gut macht, nicht nur, wo es fehlschlägt. ```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 ``` Was diesen Prompt effektiv macht: * **Nennt den genauen Fehler** – „Fremdschlüssel-Constraints“ statt „es schlägt manchmal fehl“ * **Stellt Erfolge und Fehlschläge gegenüber** – Devin kann die Session-Transkripte vergleichen, um zu sehen, wo sie auseinanderlaufen * **Listet konkrete Fixes auf**, lässt aber Raum, damit Devin Probleme aufdeckt, die du übersehen hast Devin liest alle vier Session-Transkripte, identifiziert, wo sich die Fehlschläge von den Erfolgen unterscheiden, und schlägt gezielte Änderungen vor. Die Ausgabe sieht aus wie ein Changelog für dein 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." ``` Das Playbook wird automatisch gespeichert. Wenn etwas nicht passt, antworte in derselben Session – zum Beispiel: „Füge außerdem einen Schritt hinzu, um den #database Slack-Channel zu benachrichtigen, bevor destruktive Migrationen ausgeführt werden.“ Du musst deine aktuelle Devin-Session nicht verlassen. Nachdem das Playbook-Update gespeichert wurde, verwende dieselbe Session, um eine Standard-Devin-Session zu starten, die das aktualisierte Playbook gegen genau das Szenario testet, das zuvor fehlgeschlagen ist: ```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. ``` Wenn diese Session erfolgreich ist, funktioniert der Fix. Wenn sie auf einen neuen Randfall stößt (z. B. zirkuläre FK-Referenzen), gib diese Session für eine weitere Runde wieder in den Improve-Playbook-Tab ein.

{title}