次のプロジェクトではテラコッタを検討しています。個別のDBMSを必要とせずにデータの永続性を提供できる可能性に興味を持っています。( 永続ソリューションとしてのTerracottaの使用についても参照してください)
ソフトウェアの進化における大きな問題の1つは、既存の本番データを新しいデータモデルに準拠させることです。RDBMSの場合、展開時にSQL変更スクリプトを使用する可能性があります。テラコッタに裏打ちされたデータの場合、重要な進化に対処する方法はすぐにはわかりません。
Terracottaのドキュメントにはクラスの進化に関する段落がいくつかありますが、それはDSOに固有のようであり、かなり表面的なままです。
- Terracottaに保存されている永続データのデータモデルの進化を処理するための可能な方法は何ですか?私は特にDSO以外のシナリオに興味があります(つまり、Terracotta Toolkit APIを使用します)。
- TerracottaDSOとToolkitAPIは、進化したクラス定義に対する反応が異なりますか?
- クラスの進化の限界を理解するには、Terracottaがオブジェクトデータをどのように表現/通信するかを知ることが役立ちます。そのための仕様はありますか?
- たぶん、テラコッタに適用できるOODBMSの世界からのスキーマ進化技術がありますか?
簡単な例として、たくさんのCar
オブジェクトが保存されていて、クラスのmodelYear
フィールドをaからに変更したとします。ドキュメントによると、これはそのままでは機能しません。アプリケーションの起動時に古いクラスローダーが別のクラスローダーによってロードされ、新しいに変換されるソリューションを想像できます。それは良いアプローチでしょうか、そしてなぜ(そうではない)ですか?Car
String
int
Car
Car