1

(元の質問が変更された、以下の更新プログラムを参照してください。)休止 - 親IDが含まれている複合キーを使用して - OneToMany

私はトラブルの子オブジェクトの主キーを設定休止させることがあります。主キーは親の主キーと同じです。

これは、親がどのように見えるかです:

@Entity 
@Table(name = "PARENT") 
@SequenceGenerator(name = "SEQ", allocationSize = 1, sequenceName = "seq_parent_id") 
public class Parent { 

    @Id 
    @Column(name = "ID") 
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "SEQ") 
    private Long id; 

    @OneToMany(fetch = FetchType.EAGER, cascade = CascadeType.ALL) 
    @Fetch(value = FetchMode.SUBSELECT) 
    @JoinColumn(name = "PARENT_ID") 
    private Set<Child> children; 

これは、子供がどのように見えるかです:私は、保存しようとしていますJUnitのリポジトリのテストを実行すると、

@Entity 
@Table(name = "CHILDREN") 
public class Child { 

    @Id 
    @Column(name = "PARENT_ID") 
    private Long parentId; 

親エンティティと子エンティティがある場合、例外が発生します。

org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): ... 

h ibernateは自動的にChild.parentIdをparent.idに設定しますか?

私は子供に親を与えようとしました。しかし、ParentはIdではないので、他の例外もありました。

UPDATE

私は子供のIdが本当の主キーではないことに気づきました。これは単なるマッピングキーです。 parent.idには複数の子エントリがあります。親IDと、さらに2つの文字列値:

子の主キーは3つの値のうち複合キーです:

アップデートは今、私は私が本当に必要なものを実現し始めます。

@Entity 
@Table(name = "CHILDREN") 
public class Child { 

    @Column(name = "PARENT_ID") 
    private Long parentId; 

    @Column(name = "PROPERTY_NAME") 
    private String propertyName; 

    @Column(name = "ANOTHER_PROPERTY") 
    private String anotherProperty; 

    @Column(name = "PROPERTY_VALUE") 
    private String propertyValue; 

したがって、parentId、properyNameおよびanotherPropertyを使用して複合キーをマップする必要があります。 propertyValueはそのエントリの実際の値です。

IdClassまたはembeddedIdを使用する必要があると思います。私は試しましたが、今まで成功していませんでした。

+1

リレーションシップの反対側にJoinColumnを宣言する必要があります。 'Child'クラスで' @ ManyToOne'関係を宣言します。しかし、IMOでは、設計上の問題があります。「親」に複数の「子」がある場合、「親」が「子」の主キーになる可能性はありますか? (いくつかの 'Child'は同じ' Parent'と同じプライマリキーを持ちます)。 –

+0

ああ、そうです。それは本当のプライマリキーではありません!それは単なる鍵です!テーブルには実際のIDはありません。 – Nina

答えて

1

それは意図したセマンティクスにもよるかもしれませんが、子PKも親に対してFKでもあれば、それはIS-Aタイプの関係を表していると思います。つまり、データベースではCHILDは拡張テーブルです親のために。あなたはクラスごとの継承として設定することができます。

UPDATE

は、だからあなたの更新に基づいて、子供でのParentIDは、子供のPKではありません。つまり、@Idと注釈を付けてはならず、他のFKと同様に設定する必要があります。私はParentIDをマッピングするのではなく、YMMVを使ってParentをマッピングすることを検討します。

次に、子供の一意のIDは何ですか(問題が発生している可能性はありますが、何もない場合)。それは独立して代理されたサロゲートですか?親IDを含むコンポジット?または、他の何か?これらのすべてのケースに対応することができますが、必要な情報がなければ、それぞれの可能性を詳述するのは無駄かもしれません...

+0

私はあなたを正しく理解していませんが、親が多くの子供を持つことができるので、私はそれを親テーブルの延長としては見ません。 – Nina

+0

親が多くの子を持つことができる場合、子テーブルのPKは親PKへのFKにはなりません。 –

+0

質問に更新してください... –

関連する問題