1

休止状態によって単純にマップされる単純なオブジェクトがあります

class SimpleObject {
   private int id;
   private String textA;
   private String textB;
   private Date date;
   private Status status;
   //+getters/setters/other stuff
}

ここで、私のテーブルが非常に大きくなったため (数百万のエントリ)、実際には必要のないすべてのエントリをアーカイブすることにしました (ユーザーが後でそれらを必要とする可能性があるため、オプションをチェックして、できるようにする必要があります)。実際のテーブルとアーカイブされた 2 つのテーブルを検索しますが、それは私がまだ気にしていないことであり、別の場所で行われる予定です)。
そこで、マッピング ファイルをできるだけシンプルにし、オブジェクト (アーカイブ済み/非アーカイブ済み) を変換する方法と単純な遺産を使用することにしました。

abstract class AbstractSimpleObject {
    // idem SimpleObject
}

class SimpleObject extends AbstractSimpleObject {

}

class SimpleObjectArchived extends AbstractSimpleObject {

}

Hibernate マッピングでunion-subclassを使用し、SimpleObject を古いテーブルにマップし、SimpleObjectArchived を同一のテーブルにマップしました。
これまでのところ、すべて問題ありません。オブジェクトを削除/作成/更新できます。次にアーカイブに進みます。

SimpleObjectBusinessRules クラスで、メソッド アーカイブを定義します。

class SimpleObjectBusinessRules {
    // the daos for the SimpleObject and the SimpleObjectArchived both using HibernateDaoSupport
    SODao soDao;
    SOADao soaDao;

    //...
    //you can say which objects to archive by some criterias
    public void archive(Map<String,Object> pCrit) {
        List<SimpleObject> lSOs = soDao.getByCriteria(pCrit);
        //I wrote myself a converter (based on dozer)
        List<SimpleObjectArchived> lSOAs = Converter.convertToSOA(lSOs);
        soDao.deleteAll(lSOs);
        soaDao.saveAll(lSOAs); //based on getHibernateTemplate().saveOrUpdateAll(pEntities)
    }
}

すべてのtry/catch/を省略しました...休止状態の例外が発生しますsaoDao.saveAll(...) org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session:[...]

この問題を解決する方法を知っている人はいますか? または、すでに休止状態でアーカイブを処理していて、より良い解決策を持っている人はいますか (または、休止状態でアーカイブするための実用的な解決策さえありますか)?

4

1 に答える 1

2

ビジネス ロジック セッションとアーカイブ セッションの 2 つのセッションを作成し、ビジネス ロジック セッションからオブジェクトを削除し、変換されたオブジェクトをアーカイブ セッションに保存します。DAO にアーカイブ メソッドを実装できます。これにより、多くの手間が省けます。

ビジネスロジックの他の場所で使用されていない限り（おそらくそうではない）、アーカイブロジックで完全な継承階層を汚染することはありません。2 つのセッションを使用して、アーカイブされたレコードを別のスキーマ、データベース、またはテーブルに配置するだけです (セッションのマッピングはユーザー次第です)。

ところで：マッピング戦略が原因で例外が発生します。Union-Subclass-Mapping を使用すると、すべての識別子が同じテーブル内に格納されるため、アーカイブ レコードとビジネス ロジック レコードには同じプールから ID が供給されます。その例外を回避したり、マッピングを変更したりするには、カスタム生成戦略が必要です。しかし、問題に対するより洗練された解決策 (アーカイブ セッション) があるのに、なぜわざわざそれを気にするのでしょうか?

于 2011-01-05T10:35:32.763 に答える