1

私が始めた新しい仕事では、コア ビジネス ロジックの重労働のほとんどを処理する Java アプリケーションと、もちろんこのサーバーへの Web インターフェイスを処理する Rails アプリケーションの両方を使用しています。これらは両方とも同じデータベースにアクセスします。

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

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

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

4

3 に答える 3

1

同様のプロジェクト構造があります。クライアントとしてJavaアプリケーションとRailsアプリケーションの両方を備えた共有データベースです。私は、データベースの変更を処理するためにRails移行メカニズムを使用することを提唱し、賛同を得ました。少しのレールアドボカシーと支援への意欲が必要ですが、Javaチームも独自の移行を作成しています。

ストアドプロシージャとデータベース固有の列タイプを使用する場合があるため、テストデータベースの作成にsqlを使用するようにrailsenvironment.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}を実行します）。

チーム間で通信回線を開いたままにしておくことを忘れないでください。「capproductiondeploy：migrations」を使用すると、本番データベースの更新が非常に簡単になるという事実が気に入っています。

于 2008-10-21T17:40:58.650 に答える
1

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

または、逆に Java 定義に Rails 側の変更を制御させることもできます。

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

于 2008-10-20T13:49:16.447 に答える
0

ありがとうスティーブ

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

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

ありがとう

于 2008-10-20T14:33:23.223 に答える