RailsとJavaプロジェクト間のデータベース変更の管理

Question

私が始めた新しい仕事では、コアビジネスロジックの大部分を処理するJavaアプリケーションと、このサーバーへのWebインターフェイスを処理するRailsアプリケーションの両方があります。これらは両方とも同じデータベースにアクセスします。

これまで、ほとんどの焦点はJavaアプリケーションに向けられていたため、Railsプロジェクトには移行がありません。共有データベースを更新するSQLは、changes.sqlなどのファイルで管理されます。

ご想像のとおり、これにより開発が多少難しくなります。

私の最初の考えは、JavaプロジェクトとRailsアプリケーションのコードベースを結合することでした。そこには依存関係があり、そのSQLファイルをソースで管理することでした。ただし、他の誰かがこの問題にある程度成功したかどうかを確認するために、ここで尋ねると思いました。

Answer 1

1つのアプローチは、レール移行ツールを使用し、データベースのDDLファイルを生成し、Hibernateを使用して特定のデータベースエンティティに関連するJavaオブジェクトを更新することです。 Java側でデータベースの変更を管理する方法やORMを使用するかどうかは実際には言いませんが、わずかな作業で確実に2つを同期できます。

または、他の方法で、Java定義でRails側の変更を制御することもできます。

これを成功させる鍵は、2つのプラットフォームのいずれかを「プライマリデータベースモデラー」として選択することだと思います。そのモデルを他のプラットフォームに移行するプロセスを開発します。両方からの変更を許可しようとしても頭痛の種になります。

Answer 2

同様のプロジェクト構造があります：クライアントとしてjavaアプリケーションとrailsアプリケーションの両方を持つ共有データベース。データベースの変更を処理するためにRails移行メカニズムを使用することを支持し、賛同しました。 Railsの擁護に少し時間がかかり、いくらかの意欲もありますが、Javaチームも独自の移行を作成しています。

ストアドプロシージャとデータベース固有の列タイプを使用する場合があるため、テストデータベースの作成にsqlを使用するようにrails environment.rbを変更しました。

  # Use SQL instead of Active Record's schema dumper when creating the test database.
  # This is necessary if your schema can't be completely dumped by the schema dumper,
  # like if you have constraints or database-specific column types
  config.active_record.schema_format = :sql

プラス面では、移行を伴うSQLの管理により、Railsのテストとセットアップがクリーンになります。欠点は、移行ファイルの一部がそれほどきれいではないことです（たとえば、移行DSLを使用してストアドプロシージャを生成できないため、移行で％{blah}を実行できます）。

チーム間で通信回線を開いたままにしてください。 「cap production deploy：migrations」という事実が気に入っています。本番データベースの更新が非常に簡単になります。

Answer 3

スティーブに感謝

Java側では、Hibernateを使用していますが、手動のSQL更新プロセスがあります。

どちらかでなければならないことに同意します。考えれば考えるほど、データベースだけを管理するためのアプリケーション/モジュール/コードベースをさらに追加するのは間違いなく間違った考えです。

ありがとう