画像ベースのシステムでのデータの保守/移行
通常、Webアプリケーションにはデータベースがあります。コードとデータベースは連携して機能します。したがって、 Ruby on Rails や Djangoが移行ファイルを作成する のようなフレームワーク
確かに、SelfやSmalltalk、または同じ問題に直面している他のイメージベースのシステムで書かれたサーバーもあります。コードはサーバーではなく、プログラマーの別のイメージで書かれています。
これらのシステムは、スキーマの変更、クラス/プロトタイプの変更にどのように対処しますか。移行はどちらの方向に進みますか？
例：プログラマーのアイデアからサーバーコードとすべてのオブジェクトに移行する新しい属性のプロセスは何ですか？
Gemstone/Sマニュアルの第8章 を見つけましたが、サーバーにコードを出荷するプロセスについては実際には説明していません。
Gemstoneにはクラスバージョンがあり、システム内に複数のクラスバージョンのオブジェクトを含めることができます。デフォルトでは、新しい属性を追加すると、nil値で追加されます。レイジーアクセサーを使用すると、必要なときに値を設定できます。または、アクティブな移行を実行して、新しいクラス定義をロードするときのすべての古いオブジェクトに対して、または使用されるたびに遅延して、何を行う必要があるかを決定できます。
Pharoでは、デフォルトの動作があり、インスタンス変数を追加するとそれが無効になります。つまり、新しいバージョンの読み込みが遅くなる可能性があります。 instVarを100万個のオブジェクトに追加する必要がある場合。新しいプロパティ以上のものが必要な場合は、新しいバージョンをロードする前または後に実行する移行コードを追加します。
移行ファイルベースの方法は革新的だと思います。
それ以前は、新しいスキーマは主に「コンバーター」を構築することによって作成されていました。つまり、まったく新しいイメージを作成してから、ユーザーデータを新しい形でコピーしていました。
または、イメージにレコードごとにスキーマバージョンのメタデータを含めることができるため、リーダーはオンザフライまたは（優先度の低い）バックグラウンドプロセスで移行（および新しい形式で保存）できます。最近では、ドキュメントデータベースの上に構築されているのと同様の手法があります。
ただし、小さなデルタでの小さなテキストベースの移行に焦点を当てることは、以前の慣行よりも改善されています。