2

Toplink Essentials の DDL 生成に問題があります。私は Glassfish 2.1 ベースのアプリケーションを開発しており、永続化のために JPA を使用しています。

クラス A の親エンティティがクラス B の一連のエンティティを所有するオブジェクト グラフがあります。エンティティ B には、継承を使用してモデル化されたいくつかのフレーバーがあります。そのようなフレーバーの 1 つは、他のいくつかの B エンティティをセットにバンドルする複合エンティティ クラス BC です。BC 内のすべてのエンティティ B も、B と同じエンティティ A によって所有されている必要があります。エンティティ A のすべてのエンティティ B が複合 BC の一部である必要はなく、スタンドアロンにすることもできます。

したがって、基本的には次のクラスにマップされます。

@Entity
class A {
  @ManyToOne(mappedBy="owner", cascade = { CascadeType.PERSIST, CascadeType.REMOVE })
  Set<B> bs;
}

@Entity
@Inheritance
abstract class B {
  @Id
  long id;

  @ManyToOne(cascade = { CascadeType.PERSIST, CascadeType.REMOVE })
  A owner;

  @ManyToOne(optional = true)
  BC composite;
}

@Entity
class BC extends B {
  @OneToMany(cascade = { CascadeType.PERSIST, CascadeType.REMOVE }, mappedBy = "composite")
  Set<B> parts;
}

Toplink がこのオブジェクト階層の DDL を生成すると、期待どおりにすべての外部キー制約が作成されます。ただし、制約のカスケード ルールは設定されません。

A インスタンスへの参照を介してオブジェクト グラフ全体を削除しようとすると、toplink がデータベースからグラフを正しく削除できない場合があります。含まれている B エンティティを削除する前に、Toplink が BC エンティティを削除すると、「複合」関係の外部キー制約に違反します。

この状況は、生成された DDL を関連する外部キー制約で CASCADE (または SET NULL) に手動で調整することで修正できます。これは、運用環境では問題ありません。ただし、これは、DDL 生成が toplink Essentials によって完全に管理されるインメモリ (Derby) データベースを使用するテスト環境では失敗し、上記の制約違反につながります。

必要なカスケード ルールが Toplink Essentials によって正しく設定されるように、DDL 生成プロセスに影響を与える方法はありますか?

ご協力いただきありがとうございます！

4

1 に答える 1

1

これは DDL 生成の問題ではなく、削除の問題です。

TopLink Essentials には、複雑なオブジェクト グラフまたは循環関係からの削除の解決に関するいくつかの問題がありました。最初に依存オブジェクトを削除してフラッシュを呼び出し、次に他のオブジェクトを削除するか、外部キーを null に設定してそれらが更新されるようにするなど、いくつかの回避策があります。カスタマイザーを使用してマッピング privateOwned をマークしたり、制約の依存関係を試したりすることもできます。制約を削除または延期することもできます。

削除の問題はすべて EclipseLink で修正されているため、最新の EclipseLink リリースにアップグレードすると問題が解決するはずです。

TopLinkは、DDL生成でカスケードを制約に追加する @CascadeOnDelete 注釈もサポートしています。

于 2011-03-30T13:01:46.930 に答える