ストレージ定義の変更による危険性

<td>
  ストレージ定義
</td>

<td>
  ステータス
</td>

<td>
  本棚での喩え
</td>

<td>
  クラスにはまだデータが保存されていない状態で、ストレージ定義を変更します。
</td>

<td>
  OK                                                                                             
</td>

<td>
  棚に本がない状態で、後に本が収納されるべきスロットのマップを変更します。 データなし = データ参照の問題はありません。
</td>

<td>
  クラスにデータが保存されている状態で、データを保存せずに新しいプロパティを追加し、その後でプロパティを削除して別のプロパティを追加します。 （つまり、データが保存される前に、最後に追加されたプロパティの名前を変更します）
</td>

<td>
  OK
</td>

<td>
  スロット 3 は、次に空いている棚のスロットです。 本 C がスロット 3 に配置されることを書き留めても、実際にはまだスロット 3 には配置しません。その状態で、スロット 3 は本 D 用に予約されているとしてマップを更新します。
</td>

<td>
  クラスにデータが保存されている状態で、データが保存されたプロパティをストレージ定義から削除します。
</td>

<td>
  エラー
</td>

<td>
  本棚のスロット 1～3 には本が収まっています。 マップには（スロット 1: 本 Ａ、スロット 2: 本 B、スロット 3: 本 C）と示されています。 本 B をマップからのみ削除します。 本 B はまだ棚にありますが、マップではスロット 2 が空になっている状態です。 次に新しい本を追加する際に、マップにはスロット 2 を利用できることが示されているため、無意識にスロットをダブルブッキングすることになります。
</td>

<td>
  ストレージ定義
</td>

<td>
  本棚での喩え
</td>

<td>
  何もしません。 データとストレージ定義はそのままにしておきます。
</td>

<td>
  本 B を二度と読むことがないのであれば、それを探すこともないため、マップに存在したままでも問題はありません。
</td>

<td>
  ストレージ定義に使用しなくなったプロパティが残っていることが気になるのであれば、データはそのままにして、使用されなくなったことを示すように、ストレージ定義内のプロパティ名を更新します（例: propertyA => propertyADeprecated）
</td>

<td>
  本 B は棚に置いたままにし、マップ内のスロット 2 のタイトルを「本 B」から「本 B（関連性なし）」に変更します。
</td>