Terracottaの永続データの場合、クラスを進化させる方法は？

Question

私たちは次のプロジェクトの terracotta を検討しています。私は、別々のDBMSを必要とせずにデータの持続性を提供する可能性に興味があります。 （永続性ソリューションとしての解決策）

ソフトウェアの進化の主な痛みの1つは、既存の生産データを新しいデータモデルに準拠させることです。 RDBMSの場合、展開の瞬間にSQL変更スクリプトを使用する可能性があります。 Terracotta Backed Dataの場合、非些細な進化にどのように対処するかはすぐに明確ではありません。

Terracottaのドキュメントのクラスの進化に関する段落のカップル/ a>しかしそれはDSOに固有のように思え、かなり表面的な滞在です。

1. Terracottaに保存されている永続データのデータモデルの進化を処理する方法は何ですか？私は特に非DSOシナリオ（すなわちTerracotta Toolkit APIを通して）に興味があります。
2. Terracotta DSOとToolkit APIは、進化したクラス定義に対する反応が異なりますか？
3. クラスの進化の制限を理解するために、Terracottaがオブジェクトデータをどのように表しているかを知るのに役立ちます。そのための仕様はありますか？
4. テラコッタに適用可能なOODBMSの世界からのスキーマ進化技術があるかもしれませんか？

   些細な例として、私は保存されたCarオブジェクトの束を持っているとしましょう。ドキュメントによると、これはボックス外には機能しません。アプリケーションの起動中に古いmodelYearが分離されたクラスローダーによってロードされてから、新しいCarに変換されます。それは良いアプローチであり、なぜ（そうではない）？

Answer 1

それはあなたのユースケースシナリオによって異なります。

キャッシュをロードするコストが最小限（分）で、ダウンタイムを提供することができます...それから私は新しいバージョンのためのキャッシュを再構築するだけの問題はありません。

あなたがあなたのキャッシュを作成するためのコスト（時間/日）を持っていて、かなりのダウンタイムを買う余裕がない場合は、移行期間中に新しい古いバージョンを同時に処理する必要があります。 このために：

1. 私は新しいバージョンの新しいバージョンの別のキャッシュ定義を定義します キャッシュされたクラスと古いバージョンをキャッシュ内に期限切れにさせます。
2. アプリケーションコードには、「古い/新しいバージョン」のサポートもあります。
3. データがデータまでまだ古いバージョンで動作するようなインスタンスを持っています 期限切れ/廃止された（古いキャッシュ名に基づく）
4. すべての新しいリクエスト/フローを新しいものに扱うインスタンスを持っています バージョン（新しいキャッシュ名に基づく）

   e.g。 ehcache.xmlでは、2つのキャッシュを定義します（あなたの例に基づいて）

   <cache name="com.xyz.Car" timeToLiveSeconds="600"/>
   <!--New version goes here-->
   <cache name="com.xyz.Car2" timeToLiveSeconds="600"/>
   

   .

   長期的には、バージョンの進化を含むキャッシュの命名規則を調整する必要があります。