1

基本的には、2 つの異なる基礎となるデータベースに同じ hibernate マッピング ファイルを使用するという考え方です。本番環境では、基盤となるデータベースは MySQL5 であり、テスト目的で Apache Derby を使用したいと考えています。これは、テスト目的でさまざまな MySQL データベースをセットアップして維持することを避けるためです。

DataSource のドライバーを切り替えて、いくつかのパラメーターを変更するだけでうまくいくことを願っていましたが、すでにいくつかの小さな問題に遭遇しています。したがって、実際には2つの質問があります。最初の具体的な質問は次のとおりです。

I. データ型が MySQL で使用可能で、Derby で使用できない場合、どのデータ型を使用するかを Derby に指示することは可能ですか? マッピングは次のとおりです。

  <property name="about">
    <column name="`about`" not-null="false" sql-type="text"></column>
  </property>

Derby は sql-type "text" を認識しないため、テーブルの作成を拒否します。Derby 10.4.2.0 と Hibernate 3.2.6 です。ところで。

Ⅱ．テスト用と本番環境で 2 つの異なるデータベースを使用した経験はありますか? ストアド プロシージャやデータベース固有のクエリをテストできないなど、いくつかの欠点があることは知っていますが、その一方で、テストがより簡単かつ迅速になります (最終的に実行した場合)。どう思いますか？

4

4 に答える 4

3

質問 #1 - SQL タイプを指定しないでください。代わりにHibernate タイプを使用します。

<property name="about" type="string" length="4096"/>

次に、Hibernate が提供する Derby (または MySQL) ダイアレクトを拡張して、そのタイプを (未指定の) 長さに基づいて適切な DB タイプにマップすることができます。例として MySQLDialect を見てください。長さに基づいて、文字列型をいずれかvarcharまたはいずれかの型にマップします。text

質問 #2 -開発用と本番用に異なるデータベースを使用するということですか? テスト用と本番用に異なるデータベースを使用することは、完全にロードされたバレルでロシアン ルーレットをプレイするようなものだからです。勝てません :-)

該当するすべての展開構成を常にテストする必要があります。移植性の問題を早期に特定するのに役立つため、実際に両方をサポートする必要がある場合、開発と運用に異なる DB を使用することは悪いアプローチではありません。

于 2009-11-10T18:59:03.637 に答える
1

異なる環境で異なるデータベース ベンダーを使用しても問題はありません (TEST と PROD は同じである必要があるという ChssPly76 の回答に注意してください)。私はダービーを（まだ）試していませんが。

個人的には、DEV 環境にHSQLDBを使用するのが好きです。小さく、柔軟性があり、持ち運びが簡単で、セットアップはほとんどまたはまったく必要ありません。Unitilsのようなツールを使用して、Hibernate、DbUnit、および JUnit を接着することは、私にとって非常にうまく機能しています。JUnit テストが実行される前に、HSQLDB に静的テスト データがロードされます。これにより、データ アクセス レイヤーの JUnit テストで実際のデータに基づくアサーションを使用できます (テストの近くにあるいくつかの xml ファイルから読み込まれます)。

(Unitils に関する注意事項の 1 つは、デフォルトの「loadStrategy」では、ロードする前に既存のデータをすべて削除することです。そのため、そのことを指す場所に注意してください)。

于 2009-11-10T19:22:02.757 に答える
1

私の意見では、テストで異なるタイプのデータベースを使用する主な理由は、データベースを偽造またはモックすることが実際的でない場合に、より高速な単体テストを行うためです (ただし、可能な場合は後者を行う必要があります)。テストデータベースに対してコーディングしていないことを確認するために、本番タイプのデータベースに対してテストを実行できるステージングセッションが必要であることに注意してください。また、一般的なデータベースにコーディングすることも強制されます。これは良いアイデアである場合もあれば、そうでない場合もあります。

明らかに、データベース固有の関数 (ストアド プロシージャまたは特殊な型) が必要な場合は、同じ型を使用する必要があります。

MySQL の場合、テストでテーブルを設定してメモリに格納できます。オプションであるMySQL固有のアイテムが必要になる可能性がある場合。開発/低レベルのテストで別のデータベースを使用するよりも、データベースを汎用にすることが目標である場合は、良いことです。

于 2009-11-10T19:10:58.060 に答える
0

私の経験では、テストするデータベースの実装が多いほど、データベース間で移植できないものに誤って依存していた場所をより早く見つけることができます。

Derby によってテストがより速く簡単になっているのであれば、それは素晴らしい結果です。

Derby は SQL 標準に準拠し、標準で指定されている構文と動作のみをサポートするように非常に懸命に努力しているため、Derby はテストに最適な選択肢であると思います。 - 標準データベース機能。

しかし、アプリケーションのデプロイに近づくにつれて、意図したデプロイ構成にできるだけ近い構成を使用してアプリケーションをテストする必要があることに同意します。

于 2009-11-11T17:47:59.817 に答える