新しいマイグレーションマイグレーションが既存のjOOQ生成コードを破る

Question

私は現在、自分のバイナリー（Java）マイグレーションとSQLマイグレーションを管理するために、jOOQを使用して自分のデータベースからJavaコードを生成します。

ただし、既存のテーブルを変更すると問題が発生します。たとえば、あるマイグレーションでカラムを削除し、そのバイナリマイグレーションがそのカラムに依存していた場合、そのフィールドはもはやjOOQに存在しないため、構文エラーが発生します。

マイグレーションを再開できない場合や、非常に退屈な場合（マイグレーションを1回実行する場合）、マイグレーションの本文をコメントすることができますが、Flywayやデータベースのバージョンマネージャーの全目的を凌駕します。コメントを外す、次を実行する、jOOQを生成するなど）

この問題にアプローチする方法はありますか？

Answer 1

私はこれがワークフローの問題であると主張します。

各移行で効果的にAPIをアップグレードしていますが、そのAPIの従来のコンシューマーが引き続き動作することは奇跡的なものではないと考えています。

jOOQは素晴らしいツールですが、このコンテキストで（マイグレーションを支援するために）それを使用することは確かにトラブルにつながるでしょう。

私の提案は、スキーマ進化戦略を再考することです。自然にFlywayに来る生のSQLを使用して、代わりにあなたのアプリケーションを独占的にサポートするためにjOOQを離れてください。