ですから、私には興味深い状況があります。元の開発者が列挙型とswitchステートメントを優先して継承の使用をやめることにしたコードの大きな混乱を継承しました...これはこのアンチパターンの完璧な例です 今度はリファクタリングする時が来ました、そして私は最高のものを決定しましたそれを実行する方法は、共有列を持つテーブルに裏打ちされたスーパークラスを引き出してから、結合されたサブクラス継承戦略を使用することです。ここまでは順調ですね...
ここで注意が必要なのは、このコードがすでに本番システムにデプロイされていることです。したがって、リファクタリングされたコードは、そこにあるスキーマ/データと下位互換性がなければならず、将来の1つのリリースまで、サブクラステーブルから冗長な列を削除し始めることはできません。好むと好まざるとにかかわらず、1つのリリースサイクルで親テーブルと子テーブルの間で列を複製します。
私にとって幸運なことに、親テーブルと子テーブルの間に重複する列があることを確認しても、Hibernateは反転しません。ただし、悪いニュースは、両方のテーブルで重複している列が更新されないことです。親テーブルの列は更新されますが、子テーブルの列は古くなったままになります。
現在のコードとの下位互換性のために、両方のテーブルの列を更新したいと思います。そうすれば、リリースをロールバックして古いスキーマに戻らなければならない場合でも、エンティティの更新が失われることはありません。トリガーを介してこれを処理できることはわかっていますが、トリガーにはレーダーの下を飛ぶという厄介な習慣があるため、コードのみのソリューションを探しています。
両方の列をヒットするように休止状態を説得する方法を教えてくれる人はいますか?
私のクラスの非常に不自然な例は次のとおりです。
@Entity
@Table(name = "superclass")
@Inheritance(strategy = InheritanceType.JOINED)
public class SuperClass {
@Id @Generated
Long id;
boolean duplicate;
}
@Entity
@Table(name = "subclass")
public class SubClass extends SuperClass {
String otherProperty;
}
一致するテーブルを使用して:
CREATE TABLE superclass (
id INT PRIMARY KEY AUTO_INCREMENT,
duplicate BOOLEAN
);
CREATE TABLE subclass (
id INT NOT NULL,
duplicate BOOLEAN,
otherProperty VARCHAR(255),
FOREIGN KEY (id) REFERENCES superclass(id)
);
新しいサブクラスエンティティを挿入すると、サブクラステーブルの重複する列はNULLになります。
本当にありがとう!