0

2つのデータベースの同期を維持するために、XStreamを使用してオブジェクトをシリアル化するレガシーシステムに取り組んでいます。新しいオブジェクトは最初に一方のデータベースに格納され、次に格納されたオブジェクトがシリアル化されて送信され、もう一方のデータベースに格納されます。

最近まで、問題のオブジェクトの構造は次のようでした。

public class Project {
    List<Milestone> milestones;
    [...]
}

ただし、要件を変更した後の構造は次のようになります。

public class Project {
    List<Goal> goals;
}

public class Goal {
    List<Milestone> milestones;
}

目標について何も知らなかったレガシーデータのマイルストーンを維持するために、プロジェクトの最終的な構造は次のとおりでした。

public class Project {
    List<Goal> goals;
    List<Milestone> milestones;
}

したがって、プロジェクトからマイルストーンへの2つのパスがあり、1つは直接、もう1つは目標を通過します。この構造が逆シリアル化されて保存されると、問題が発生します。XStreamによって逆シリアル化されると、プロジェクトに接続されたマイルストーンのオブジェクトは、同じIDを持っていても、目標を介して接続されたオブジェクトとは直接異なるオブジェクトになります。

HibernateのSession＃merge（）を使用してこのオブジェクトを永続化する限り、merge（）はdb識別子が同じである限りオブジェクト識別子を気にしないため、問題はありませんでした。

しかし、この目的でmerge（）を使用することはできなくなり、代わりにSession＃save（）に依存する必要があります。そして、save（）はオブジェクト識別子に注意してください！そのため、逆シリアル化されたオブジェクトを保存しようとすると、org.hibernate.NonUniqueObjectExceptionが発生します。

これを解決するための最も邪魔にならない方法は、可能であれば、XStreamにデータベースIDごとに1つのオブジェクトを作成させることだと思います。しかし、これは可能ですか？

4

1 に答える 1

0

いくつか検討したところ、オブジェクト参照のメカニズムがあるため、問題はXStreamではないように思われます。問題は、私が取り組んでいるプロジェクトのもう1つの気の利いた「機能」です。各ドメインクラスには2つのバージョンがあり、1つはHibernateとの通信用で、もう1つは「ロジック使用」用です（理由は聞かないでください...）これら2つのバージョン間の変換（基本的に1つのオブジェクトから別のオブジェクトに値を移動する）では、オブジェクトが無批判に新規作成され、同じ「Hibernateオブジェクト」が複数の「Javaオブジェクト」に変換されます。次に、これらが同じである必要があることを理解していないことでXStreamを非難することはできません:)

于 2013-03-19T08:54:37.053 に答える