問題タブ [table-per-class]

いくつかの情報源は、NHibernate が具象クラスおよび共用体サブクラスごとのテーブルで ID を使用できないと述べています。これは本当ですか?この背後にある正確な理由は何ですか?

レガシーデータベース上でEntityFrameworkCodeFirstDALを作成しています（つまり、ほとんどの場合、設計エラーが発生しても問題が発生します）。

ドメインモデルは（かなり）単純です。HomeCard、CarCard、OwnerCard、RenterCardにサブタイプ化された抽象的なカードがあります。正確には：

データベースモデルは、Cards、Homes、Cars、Owners、Rentersのテーブルでそれに続きます。ここで、Cardsには共通の列が含まれ、他のテーブルには特定のクラスに関連する列が含まれます。これはまさにTPTの意味であり、EntityFrameworkに完全にマッピングされます。

リファクタリング後、（予期せぬことではありませんが）HomeとCarがいくつかのプロパティを共有し、OwnerとRenterが同じことを行うことがわかりました。そして、それは美しさのためだけでなく、いくつかの機能は実装がはるかに簡単です（たとえば、名前で所有者と賃貸人を検索したり、所有者で家とカードを検索したりします）。したがって、ドメインモデルは次のようになります。

ただし、同じdbモデルがまだあります。つまり、TPTとTPCの間に奇妙な組み合わせがあります。EF/CodeFirstを介してマップする試みはすべて失敗しました。それを機能させるためのアドバイスはありますか？

PS私たちのベーステーブルであるカードには、何か助けになるかもしれない場合、ディスクリミネーターフィールドがあります。

できる限り単純でわかりやすいように、不自然な例で問題を説明します。ただし、私の本当の問題はレガシー コードにあるため、スキーマなどを変更することはできません。

コードにクラス階層ごとのテーブルがあります。Customer1 と Customer2 としましょう。それらには、固有の識別値 (それぞれ 1 および 2) があります。各顧客は、0 個以上のアドレスを持つことができます。アドレスは 1 つのテーブルに格納されます。このテーブルには、顧客 ID と顧客識別子の値への参照が格納されます。私が持っているアドレスマッピングでは：

これで問題ありません。ただし、customer1 と customer2 のマッピングには次のものがあります。

これには、id 1 で customer1 をロードすると、id 2 で customer2 のアドレスが取得されるという問題があります。私の最初の修正の試みは、セットに複数のキーを追加することでした。

ただし、それを行うと、次の例外が発生します。

org.hibernate.MappingException: 外部キーには、参照される主キーと同じ数の列が必要です)

誰もこれに対する解決策を持っていますか。ある種の仮想複合キーとしてディスクリミネータをクラスにマッピングする方法はありますか? または、特定の顧客テーブルに制限するためにセット マッピングでできることは他にありますか?

ご感想ありがとうございます

私はエンティティ フレームワーク 5.0、モデルを最初に使用しています。

テーブルは、クラスごとのテーブル (または具象型ごとのテーブル) パターンを使用してマップされます。

表 A 1..多数 (抽象) 表 B

テーブル B には 2 つの子クラスがあります

B1 & B2

B2 には 3 番目のテーブルへの外部キーがあります。たとえば、テーブル C (多くの B2 ... 1 C) としますが、これは親クラス B のプロパティではありません。

Eager ローディングはアプリケーションのデフォルトであり、テーブル B2 でクエリを実行するときにテーブル (またはコレクション) C を含めたいと考えています。

このテーブルの熱心なロードを強制する方法について考えてくれてありがとう

バックグラウンド

EclipseLink (バージョン 2.3.2.v20111125-r10461、JPA 2.0 仕様の実装プロバイダー) を使用しています。

Person@MappedSuperclassと呼ばれるこれを考えてみましょう:

彼は抽象的で、彼にはリスナー ( Listener ) が付いています。リスナーの実装は次のとおりです。

次に、Personを拡張するEmployeeクラスがあります。

Employeeはまだ抽象的であり、インスタンス化することを意図していません。ただし、 Employee は関係の一部である可能性があると考えられているため、注釈が付けられて@Entityいます。階層は、PartTimeEmployeeと呼ばれる非抽象エンティティに続きます。

PartTimeEmployeeはインスタンス化されることを意図しています。それを試して、何が起こるか見てみましょう! 細かい点を除いて、すべて正常に動作しているようです。@MappedSuperclass Personに登録されているエンティティ リスナーは呼び出されません。@EntityListenersアノテーションをPersonからEmployeeに移動しても、リスナーは呼び出されません。

1 つの修正

@EntityListeners注釈をPartTimeEmployeeまで移動すると、彼が呼び出されます。うーん。

別の修正

Personにリスナーを登録したままにすることができ、 Employeeのアノテーションを完全に省略した場合、リスナーは意図したとおりに呼び出されます。しかしもちろん、私は望んでいない単一のテーブル戦略を手に入れました。同様に、ストラテジーの値を から に変更すると、リスナーが呼び出されます。もちろん唯一の問題は、データベース スキーマが思い通りにならないことです。@InheritanceInheritanceType.TABLE_PER_CLASSInheritanceType.SINGLE_TABLE

したがって、ここでの問題の核心は、従業員@Inheritanceクラスの注釈 (より具体的には、クラスごとに 1 つのテーブルへの戦略の変更) であり、階層内のエンティティ リスナーに関するすべてを EclipseLink に忘れさせます。

それは私が期待していたものではありません。私が理解できないのは何ですか？

概要

InheritanceType.TABLE_PER_CLASS; の 2 つの単純な @Entity 継承ツリー (各ツリーに 2 つの具象実装クラスを持つ 1 つの抽象基本クラス) があるとします。@JoinColumn を使用して基本クラスを接続する双方向の @OneToMany リレーションが必要です。

これにより、具体的なクラスごとに 1 つずつ、合計4 つのテーブルが生成されるはずです。EclipseLink は、意味をなさない抽象基本クラスの 1 つの 5 番目のテーブルを生成します。次の例を考えてみましょう (これは実際の例ではなく、JPA に関するものです)。

例

Collection は、最初の継承ツリーの抽象ルートであり、@OneToMany 関係の実装者です。

PhysicalCollection と VirtualCollection は Collection の具体的な実装です。

Media は、2 番目の継承ツリーの抽象ルートであり、@ManyToOne 関係の実装者です。

CdMedia と TapeMedia は Media の具体的な実装です。

結果

前述したように、EclipseLink はこれから5 つのテーブルを生成します (SEQUENCE テーブルは気にしないでください)。

また、予期しないテーブル MEDIA には役に立たない定義があります (PhysicalCollection の名前を変更すると、外部キー ターゲットのセマンティクスが変わります)。

質問

1. 私の期待は正しいですか？(5 つではなく 4 つのテーブルを作成します)
2. これがEclipseLinkのバグであることを誰かが確認できますか?
3. バグでなければ、どこが間違っているのか指摘してもらえますか?

エンティティのコレクション (マップ) を継承でマップしたいと考えています。エンティティと継承エンティティは次のようになります。

マップ値として使用されるエンティティはこれです

そして、ここにテストコードがあります：

これまでのところ、すべて正常に動作しています。EclipseLink は、TestEntity と SubEntity を、クラスを区別するための識別子列を持つ 1 つのテーブルに配置します。また、完全なマップ データは MapValueEntity のテーブルに格納されます。ここで、マッピング戦略をデフォルト (= SINGLE_TABLE) から TABLE_PER_CLASS に変更すると、構造が壊れます:

例外の説明には次のように書かれています。

フィールド [MAPVALUEENTITY.MAP_KEY] には複数の書き込み可能なマッピングが存在します。書き込み可能として定義できるのは 1 つだけで、その他はすべて読み取り専用として指定する必要があります。

このシナリオで TABLE_PER_CLASS 戦略を使用する機会はありますか? 「複数の書き込み可能なマッピング」はどこに記載されていますか?

それは質問ではなく、将来のためだけです... (理解するのに多くの時間を費やしました)

マッピング (Fluent NHibernate):

BMap オブジェクトを永続化すると例外が発生します:

例外：

内部例外:

この明白でない例外は、マッピングの設定ミスが発生したことを示しています。実際、「選択」クエリはかなりうまく機能します。ただし、「に挿入」(ISession.SaveOrUpdate) すると、前述のエラーが発生します。

修理：

AMap クラスでは、その行は必要ありません:

この永続化を削除した後、正常に動作します